Learning from Anemic Reviews - Improving your Agile Feedback Loop
Consider an agile utopia executing a lean build-measure-feedback loop for software development. How would you feel if your biggest strength of receiving early feedback from your end-users turns out to be your Achilles heel? Recently I faced this dilemma where my end-users unfortunately were a group of introvert individuals. This led to Monger project’s MVP almost declared as a failure since it did not fulfill the end-user’s requirements.
Many a times, projects transform their delivery mechanism from traditional models to agile with a myth that agile is a recipe for success. In reality many projects fail since agile is not well understood by the teams. A few times (like in this case) the agile process falters not due to incorrect implementation but due to incorrect participants responsible to execute a part of the process.
Experience with me what happens when your end-users falter your feedback loop just because of the nature of individuals. If you’ve ever been a part of a group (or may be in the future) where your end-users are introverts, learn from this experience report how we overcame this problem on the Monger project by strengthening our anemic reviews. At the same time, if you as a participant have been there and done that, I would love to hear about it.
Outline/Structure of the Experience Report
- A flashback of the Monger project
- The root-cause analysis
- The astonishing observations
- The solution that fixed the loophole
- Open discussion to share more ideas
- Retrospect if you've been in a similar situation
- Suggestions to improve the user feedback loop on projects
- Share your experience if you did things differently
Anyone who has faced (or may face in the future) a group of introvert end-users who shy away from providing valuable feedback, only to complain post production.
schedule Submitted 5 years ago
People who liked this proposal, also liked:
Anand Murthy Raj / Sundaresan Jagadeesan - Philips - Enterprise SAFe Transformation JourneyAnand Murthy RajAgile CoachGladwell Academy and Blinklane Consulting NLSundaresan JagadeesanProgram ManagerPhilips
schedule 5 years agoSold Out!
About the company
Philips is a healthcare multinational company that focuses on building complete health care products and solutions for emerging markets, in addition to developing solutions and products for global markets, across the three sectors Healthcare, Lighting and Lifestyle. Using the expertise of its nearly 2000 engineers in Bangalore and aligning the marketing and sales teams the campus is responsible for creating and rolling out a complete set of products that include a whole host of solutions for global customers. It also contributes to global solutions in critical health care component development for connected consumer devices and renewable energy.
Beginning of 2014, an external survey brought out the issues wrt time to market and code quality. Taking the survey results positively, the Leadership embarked on an Agile/SAFe journey with pilot projects. The results were amazing and with the currently learning from the pilots, the organization is running 25+ deployments within. The journey has started and Agile release trains are delivering periodic value to our customers at defined frequencies.
Product quality, consistent & predictive delivery and quicker time to market are the key challenges the organization is trying to address today. Continuous Innovation is constrained due to the above issues and hence there is need to find a new way of product development which can meet the dynamic business needs, foster people engagement and deliver meaningful products to the world.
ScaledAgile has been used as a framework for product development across the organization global. The whole organization is undergoing a transformation from waterfall way of working to the SAFe agile way of working and roadmap is till 2019.
The Framework used for the transformation can be summarized into 4 major steps
- Develop products in the Agile way with focus on Basic Agile practices (Scrum)
- Establish Product Ownership with focus on Enabling Scaling aspects (SAFe practices)
- Establish a release pipeline with continuous integration (supported by Automation)
- Adopt a DevOps Culture with focus on Continuous delivery (to production environment)
This includes a comprehensive diagnosis of the various business processes, agile practices and behavior, engineering practices, delivery maturity and recommendations for the transition. A coaching and tooling plan is also an outcome of the diagnostics.
- Predictable Releases to customers (hitting the market with features every three months with features and business criticial bugs with less than 2 weeks with all the regulatory compliance)
- Feature planned vs Feature delivered per program increment > 80%lose
- Defect reduction co t 45%
- Team velocity – Baseline vs actual.
- Very high sense of ownership and high levels of engagement
Transformation team Profile
- Agile Capability program manager -1 FTE
- Agile Deployment Program Management – 1 FTE
- Communication expert – 1 FTE (Today we are 0/1)
- Coordination - 1 FTE
- Enterprise Agile Coaches – 16 (Today we are 9 /16)
Munish Malik - Measure What MattersMunish MalikLead ConsultantEqual Experts
schedule 5 years agoSold Out!
While working with Agile projects, tracking and showcasing the progress of the project is an integral component that is of special interest to the account managers, product/ project managers, product owners and business stakeholders. A typical Agile project would be working with estimates, story points, velocities, burn-up or burn-down charts.
I have witnessed numerous sprint reviews and showcases where the business is only waiting to see those few slides of the presentation where there is the "actual" red worm, running against the "planned" green worm, trying to catch-up. If the red worm is ahead, I have seen a smile on the faces of the stakeholders. If it matches the green one, there is a sigh of relief. And as a development team you should just pray that the poor red guy is not falling behind the green one, lest it might lead to a lot of questions starting with why, how, what etc.
There have also been times where there have been some unfortunate heated discussions that last forever on why did the team end up not claiming a few points that they had committed. What gets lost is what the team accomplished in the sprint that adds good value to the product. There have also been times where the estimates are being questioned by the product owner or account managers. If you are working in a distributed setup where the product owner is working out of a different country, the problem is even bigger.
Let us think about a scenario where the project gets completed on time, budget and scope. Majority (or all) of estimates were correct. However, when the product went live to the market it failed big time. What is the use of building such a product?
Are we focusing too much on numbers and points and overlooking the other important aspects of Agile software development such as producing software that delights the customers and looking for ways on how we can measure that? Are we measuring if we are creating a solid, robust and a scalable platform that is ready for future developments and enhancements? Are we measuring the outcomes of the time we are spending in the shoes of the people who will actually use the software?
The objective of this session is to promote the thinking of measuring what matters for your project. To measure the goals that your software development wants to achieve. I don't plan to showcase an exhaustive list of measurements that can solve all your problems, however, I instead want to highlight some samples that I have used in my projects with the help of my team, that helped us to measure things that add value to the business and development v/S simply creating burn down charts.
Majorly, I want to encourage the audience of this session think out of the box to identify what measurements will really matter for your projects. Perhaps from the eyes of the users and business and see what things if measured will add a lot more value than simply estimates, and will help in creating a valuable product that will truly delight the business and the users of the product.
Munish Malik - Project Manager from HellMunish MalikLead ConsultantEqual Experts
schedule 5 years agoSold Out!
A Project Manager plays multiple roles in the organization. He or she has a role towards the team, towards the project, towards the business stakeholders and towards the organization itself.
The days of traditional project management evangelizing the concepts of "Command & Control" are long gone. Especially with Agile software development, the focus is more and more on building self managed teams.
It is said that it is easy for a project manager to lose his or her mind :D. Especially if you are under constant pressures of reporting project financials, status reporting, managing your project staffing & recruitment, stakeholder management, distributed teams, risk management, project planning, inceptions, lift-offs, project governance and to top it all, leading a group of different psychological beings who may be responding differently in different situations. There is no one size fits all when it comes to working with human beings, and you have the onus to build a self managed team. Hence, probably it is more apt to call our breed as project leaders than managers, but let us leave that discussion to a different day.
So if you are a project manager and getting stressed due the above mentioned pressures, or if you are clinging to the past styles of project management or you like being "old school", you may not realize but you might have turned into a devil.
How to be sure? Well... this session will offer you a checklist to confirm how close you are to being a devil or already have become one.
Harshal Pandit - Visualizing the Big Picture in Agile projectHarshal PanditSAP CRM ConsultantCrest
schedule 5 years agoSold Out!
As a Business Analysts, often we have to work in the two worlds of Business and Technology.These are the two vast fields with multiple areas that the BA is expected to keep an eye on.
But once your project grows bigger, teams start to get lost in big bunch of user stories and then it gets harder and harder for everyone to see the same big picture of your project
From my past experience I find the biggest difference between being an Agile BA and a BA working in waterfall is the scope of the requirements we create. Before I'd work on the requirements for the whole system and get sign off on the whole thing (Blueprints). Now that I am working on a Agile project in Scrum team, I get the Epics for scope before the project starts, but then everything's explored in the span of the 2/3-week sprints.
We may take an epic and break it down into several stories, but We are only getting detailed requirements for the next 2 or 3 weeks. It is rather challenging to be thinking small, but also thinking about the whole process or even about the organization as a business analyst of a particular project.
Sometimes it can be easy to get lost in the middle of iterations and forget about the big picture of the final product. I would say that is a real fight you have to figure out how to win with the correct balance of sprints and overall project deliverables in Agile project as a business analyst.
So if you are also facing a same issue of poor visualization of big picture in your agile project then join my session to know how we have tackled this issue and able to visualize the big picture.
Ashish Pattnaik - Agile Reinforcing technology platformAshish PattnaikSAP FICO ConsultantCrest, A Springer Company
schedule 5 years agoSold Out!
I would like to suggest Agile ASAP methodology. It provides clear description of how to do visual blueprinting. It definitely does not leave the scope definition or blueprint open until Realization stage. Even in pure SCRUM projects you start with definition of the backlog which is exactly what we do in the front end of the project.
We do either Scope Validation (in case we have a good baseline build that we can start with) or Lean Blueprinting which has objective of completing the backlog of work for the Realization stage. Where we differ is that the full design work is not done in Blueprint, but rather some of the more fine elements are left for Realization. This gives the team ability to better react to changing requirements resulting from end-users (product owner) understanding the solution capabilities better. We also recommend to use value based decision making about modifications or enhancements.
I assume that your main concern is scope management after the backlog is completed. This is especially important in relationships where customers contract companies to deliver the solution. In my mind the fact that the methodology is open to product owner introducing changes does not preclude the contractor from adhering to the contracted scope and handle any out of scope items as scope change requests.