Introduction
If you are a business/IS manager and would like to know more about Agile Delivery, read this story of real-life experience. I covered the business “Target” aspect (Why?) in part-1 and the “Technology” aspect (What?) in part-2 of my blog. I conclude with the delivery approach (How?) that is based on the “Team” and Governance.
CONCLUSIONS
- Agile Delivery: is a great approach to implement non-critical solutions in a Minimum Viable Product first release and several regular small-to-medium enhancement releases. It is not optimal for mission critical (e.g. Finance, Supply Chain) business processes as they require full picture design, impact assessment and testing on a snapshot of data. You can’t really say 80% of the processes and data are correct and we will fix the rest later…
- Product Owner (PO): is the critical role to Engage, Explore, Evaluate and Expand on the real business drivers and stakeholders. A good PO can prioritize the backlog to navigate the team well.
- Agile Project Manager (PM): is useful if the Scrum Master and the Product Owner can’t focus on governance enough and there is a strong current from the IS/Business stakeholders to manage.
- Scrum Master (SM): is the other critical role to create a regular rhythm and unblock the team, plus maintain a fact-based open communication style.
- Quality Analyst (QA): is the third key role, who can understand the end-to-end dependencies of quality outputs and not just a tester who can “execute” test cases.
- Developers (DEV): are the brain of the team, and if they are proactive and transparent than any technical challenge can be solved.
Background
So we were requested to evaluate, build and run a global social intranet with 22,000+ users. We implemented it in a 6 months agile delivery with a big-bang go-live and several fortnightly enhancements. It had high executive visibility and expectations from our internal and external stakeholders. But initially, the governance was far not robust for such a wide user group implementation.
Initial Structure
At the technology selection phase, we had a capable young Business Analyst working with us to define initial requirements and the solution fit.
- After the selection was done and the budget secured, a professional Product Owner (“PO”) joined, who quickly shifted the expectations into a higher gear. The originally agreed Minimum Viable Product approach turned into a “best possible” approach.
- The Business Analyst was assigned to the Project Manager (“PM”) role, but a few weeks later she left the organization to overseas.
- So the PO picked up the PM role but had no time and deep experience working on governance and finances.
- So the Scrum Master (“SM”) started helping with the PM work.
This setup proved to be far not enough for the weight and constraints of the project. Crysis situation escalated. The external stakeholders on both sides wanted to understand why we can’t deliver on time and on budget. We were all confused and frustrated.
Optimised Structure
On several heated executive meetings, our team could prove that we reported weekly the project to be in the “Red” status. It took a few weeks to understand that the initial “Green” start turned into “Amber” with decision delays, confusion on the UI design and more plus more technical limitations were uncovered. The vendor executive managed the situation well and stood behind the team. It was an amazing support.
The client finally assigned a professional Project Manager to the team. Nothing else changed in the team, but everything changed in the project.
- The PM reviewed the scope, finances and engaged with all the key stakeholders to put our project back on track.
- Also, the Digital Architect supported the team with great insights, suggestions and sometimes surprising details.
- The PO worked on the stakeholders together with the PM. The Scrum Master helped the PM to understand the scope, velocity and the blockers.
- The QA defined quality risks and the PM helped him to influence the Test Portfolio Managers to let us do Agile Testing (means just enough for the sprint) instead of full end-to-end test and documentation fortnightly. Everything started working well again.
Results
Due to the balanced team structure and because everyone worked super hard in his or her positions - like a great rugby team - we scored try after try. We started enjoying working together and the daily standups became more practical and faster. The dependencies were managed with other vendors and there was a hierarchy of roles so the escalations actually worked. The go-live was high risk and tiring but successful. The fortnightly enhancements were focused on the user feedback and on calculated risk/value. Not everything was perfect though, but we improved week-by-week. We felt great.
Permanent Team
After a few enhancements, a new Product Owner joined in a permanent position, plus our developer and quality analyst have also changed. The PM rolled over to another few critical projects to save. Just the Scrum Master is the same, we rebuilt the team and continued on the roadmap.
- The new PO proved to be practical, realistic and highly professional accepting the fact that he didn’t know everything. He learned how to use JIRA and communicated about expectations and deadlines clearly.
- The new Quality Analyst stepped up from being a tester and influenced the user stories before the sprint planning started. Still, we had many user stories and bugs half-defined by the PM/SM who did the Business Analyst role part time. But at least we had high trust in the team to challenge each others.
- The new Developer was really quiet, but after a few weeks he suggested much better solutions and optimized the user experience, without us asking him.
- The Scrum Master started shifting sprint demo/retro/planning meetings to Friday afternoon off-site workshops. So the full squad attended and was uninterrupted. We deeply immersed in our work and enjoyed working together.
Lessons Learned on Agile Team
- Core Squad: PO, SM, QA, and DEV can Perform if they are a stable team after Forming, Storming and Norming. Leave the team unchanged for 3-5 sprints and they will evolve and amaze you. The structure encouraged ownership of product quality for each team member. From that ownership came the drive and movement towards becoming a truly cross-functional team.
- Agile Governance: Agile Project Manager and Executives are critical in case of complex, high impact changes. You can’t assume that the Core Squad can solve organizational challenges and dependencies. It is just not fair.
- Extended Squad: The UX/UI designer, security analyst, test automation analyst, functional consultant, delivery lead, a business consultant can come and go, but they need to adjust to existing standards.
- Release and Test Management: Release Train Engineer and Test (Portfolio) Manager can support the squad superbly if they understand JIRA and Good-Enough, Just-in-Time administration.
Lessons Learned on Agile Delivery
- Management Processes and Tools: If there are documented standard processes and approvals, sooner-or-later an agile team can use them efficiently. But if there are shifting goalposts, then speed and quality drop drastically. The deployment and test notes become a “Digital Jungle”. The more automation testing and JIRA use are implemented, the easier is to run a sprint/release. The reliability of the existing release process took a lot of the pressure off.
- Constant Re-prioritisation: Business is a dynamic environment and outside of a sprint it is normal to change priorities regularly. But once an agile sprint=release is locked in, NO change is possible only unblocking issues.
- Incremental Changes: Nothing is final in an agile solution and everything can be improved. Therefore it is better to go for a good-enough release and ask for forgiveness and feedback from the users, than wait and spend more on assumptions.
- Frequent Escalations: Unblocking small-to-large issues is the key in agile delivery. We can’t afford to wait. So the closer the business/IS stakeholders are, the faster they can help WHEN needed. :)
Author
Laszlo Csite is a freelance project/product manager and scrum master, who enjoys working on lean-agile projects to deliver flow user experiences and productivity using digital experience platforms.
He does this by helping businesses to identify opportunities, plan and implement Salesforce Communities or other solutions to improve their customer/employee/partner experiences. He has been working on business/IT initiatives as a consultant and manager in the last 20+ years. Laszlo has a good understanding of ERP, CRM and Web/Mobile solutions and how they best integrate with each other. He can help you find answers and get people to agree on a roadmap and best next steps. Feel free to ask him about lean product management, agile delivery and innovation/information/interaction/integration solutions and their measurement.
Tags: #lean #agile #digital #user-experience #productivity #social #intranet #salesforce #communities