Scrum Master and Team Training @ Nokia (part 2)
Following some more pictures from the Nokia training experience - already more than 15 teams have been trained and coached by agile42 in the last 6 months - were I'll try to point out some more interesting highlights...
Even in only 5 min. of time, after 2 Sprints and 2 Team Retrospectives the teams greatly improved their ability to self-organize and collaborate. You can't imagine how many hands are building together on the same "story" and how well synchronize the team members are sorting out pieces, putting them on top of each other to achieve the common goal, fulfilling the Acceptance Criteria.
A fundamental Best Practice for every agile team is to constantly reduce the complexity of the product they are building without reducing the features and at the same time make it more easy to maintain and evolve. An healthy product is a very important asset for a company, especially when in uncertain market conditions the company - through the Product Owner - needs to adapt very fast to market changes or follow specific customer requests.
Only with a "clean" and well "tested" product the Team will be able to follow significant changes of tactic, and priority without breaking apart. A fundamental point of Scrum is that the Team must deliver at the end of every Sprint a potentially shippable product.
Only in this way the Team with the Product Owner can inspect & adapt on the status of the product and find ways to improve it. Often the Product Owner doesn't have clear ideas on how the product should finally look like, but he has clearly in mind what need the product has to fulfil, in this way the Team is free to reach the defined goal combining creativity, experience and user needs.
Sprinting successfully requires preparation and "training", so in Scrum teams learn to prepare themselves for the next upcoming Sprint, investing a bit of time in the current Sprint (about 10% is what we can measure by experience).
This time is very important for the team to prepare themselves for the upcoming Sprint Planning Meeting, and make it an effective planning session instead of a Surprise Party. The look-ahead is about having a look at what is in the Product Backlog and checking together how to solve those items, discuss with the Product Owner, review and negotiate the acceptance criteria if needed. Important is that the team understands and start to think about what changes and which part of the product should be modified.
Release (Alternative) Burndown Chart
Often during our coaching experience comes out the sentence of "Scrum being good only for doing small things... and change management" stemming mostly for the "understanding" that in only two to four weeks, it is not possible to build real big features. Well it is somehow true, but the point is that Scrum is not about developing a product in one iteration, but developing a product one release at a time, and one sprint at a time. The Product Owner shares the vision with the Team(s) and based on the Team(s) Velocity set down a Release plan, containing her expectations. A release is often spanning through 3 or more sprints, therefore the Product Owner and the Team need to monitor the progress one iteration after the next, keeping under control the amount of work still to be completed.
Being Proud & Celebrate the achievement... or not?!
Even if the Product Owner "expects" the Development Team to deliver, and implement the best product on the market, this doesn't mean that it will happen. The complexity of fulfilling customer and user expectation is actually very high and a well known cause of project failure (@target=new Standish Group - Chaos Report; meeting customer expectations requires close collaboration, and frequent delivery, like Lean teaches us, deliver as fast as possible, to learn as fast as possible.
Development Team, Product Owner and Scrum Master - all together a Scrum Team as Ken Schwaber calls it - collaboration is fundamental to reach the customer expectations, and often they exceed them... for this reason is important to recognize the success and celebrate when the Scrum Team exceed them, raising the bar for the next Product Release.
Scrum teaches everybody who practice it, that you never finish to learn and to improve, and this happen through failures and mistakes. These are probably the most valuable lessons a Team can go through to become a Team and... a Good Team and... a Great Team :-)