|As we always say, every new training is a new experience, and you never stop to learn something, which is the exciting part of the job... at Ericsson has been another very interesting experience, and again we learned something together |
Author: Andrea Tomasini, Certified Scrum Coach and Founder of agile42, www.agile42.com
Negotiation is the key, talk to the Product Owner...
Ericsson team negotiating the content of the Product Backlog... The Product Owner prepares the Requirements and Stories and put them into the Product Backlog, sorted by Business Value, so that the items more valuable are considered first. Some times the Product Backlog is misunderstood to be a Plan, given from the Product Owner to the Team, as a Project Manager would plan for a projet... it is not - at least literally not - it represent the order in which the Product Owner would like to deliver value in form of product features.
This is not the case in Scrum, and in any other Agile method, where the Development Team has to negotiate and discuss Stories, until they are clear enough and understood by the whole team. One important goal to reach at the Sprint Planning Meeting, is for the Product Owner and the Team to make sure that there is a common understanding about the content of the Backlog, to maximize the advantage of having a full-bandwidth-communication instead of a Specification sign-off.
The Development Team can than ask the Product Owner to change, split, reorganize, partition each Backlog item, to better fit their Sprint capacity, without altering the Product Owner needs.
Never take the Product Backlog as given, the Development Team is responsible to deliver an high quality product, and this includes under many aspects also functional consistency, usability, performance, security... all things that have a direct impact on Stories, for this reason the Development Team must be sure that what is build is not breaking the "Product".
Of course the Product Owner is the ultimate person who will have to make a decision, but the Development Team has the responsibility to advice, notify and sometimes "refuse" Stories which are going to hurt in one way or another the Product. Scrum it's all about common sense, and finding the right way to deliver value and quality consistently at every iteration, this entails a learning process that often needs to be strongly supported by the Scrum Master
Ericsson guys & lads started to negotiate already at the first Sprint Planning, demonstrating an high level of commitment and an attitude to collaborate and propose alternative solutions.
Team Collaboration is not only a reactive solution
Ericsson team effectively collaborating, after a proactive plan Many times the Team Collaboration is seen as a Reactive Solution to emergency or delays during a Sprint. Indeed if the Team is on-late with the Sprint commitment, everyone tries to help out and solve as fast as possible the problems, but there is more than that!
The value of a cross-functional team and people with different skills, strongly lays in the capability of sharing knowledge and expertise and this is of great value to the Team and to the Product. This should not only happen during the emergency time, under pressure, but should possibly become the way for the team to work together, and adopt a consistent approach to "Product Development"... something like:
* Analyzing a Story all together, understanding all the aspects of it, may be already having a look in the code and check which part of it need to be changed, adapted, improved.
* Planning in detail, sometime writing comments in the code all-together, or writing detailed tasks on what needs to be done in order to make the Story Potentially Shippable at the end of the Sprint.
* Doing everyone sleeves-up hands on the keyboard, and Los!
* Verifying all together review the plan made, what can be improved, what we forgot...
Scrum define specific moments to do all these actions, at least once per sprint, but why don't take it as a best practice and a "common sense", imagine to approach every story in this way, work together as a team, focused, and deliver... that's Collaboration! And look at the Team well organized, following the just-in-time plan, and ready to verify the outcome on the run, great
Learning by doing, and Failing. Do not underestimate any Story... it may cost you a lot!
Ericsson team members struggling with an apparently very simple problem... Everyone learns this by doing... or not? That's the point, often we make mistake and we believe that we learned not to do those mistake anymore... than one day, oh no... again! Why does this happen? Should an adult have learned to consolidate experience and make sure it becomes an asset? Well sure, most of us do, but than where is the problem?
A Team is not an individual, but many! And to consolidate the experience of the individuals into the Team, requires a bit more of work, than just what our brain - nearly naturally - provide us. We need to make sure that what every individual, or member, of the Team learns, becomes as fast as possible an asset, for the whole Team. This is the core of the "Build Knowledge/Amplify Learning" principle, it is up to every Team to define best practices to make sure that good results will be repeated
Sometimes also a "looking simple" task, under stress and pressure, may become a nightmare, a never ending story... does the Team know how to deal with this? Is the Team aware of the fact that a member is struggling without coming to an end? Is that member aware that sometimes it is needed to raise the hand and ask, and that doesn't mean "being not good enough" but means "being responsible"! Apparently not always We fear to understand that individual proud, ego and satisfaction are second to a common goal, and are spendable in favor of serving the Team... this is what an Agile Leader does!
So taking 4 Sprint to fix the roof of a LEGO house, may look really unrealistic, but it may still happen, important is that the Team learn as a Team and sets the adequate best practices to establish that learned lesson into the Team culture and assets.
Inspect & Adapt... not only with the stories
Ericsson team inspection and adaption... a way of living The core of empirical approaches to "Problem Solving" lays in the capability to Inspect & Adapt, learning by doing... Scrum is not different. When people start to understand that abandoning the world of the "defined" and jumping on the train of "trying it & improve it" is not only as much safe, but also much more exciting, it becomes a way of living... and it is not Anarchy!
Inspecting and Adapting is a conscious action, something that requires agreement, and "just-in-time" planning and verifying, so basically the motto becomes: "We do it this way... until we find a better one!"
When the infrastructure is not there, and you need to deliver, you do the best you can... always
Delivering value is what it matters, and doing it often is what gives you satisfaction
Ericsson LEGO city Delivering something valuable often is much more important than delivering something perfect one day This is Lean thinking, focus on delivering something valuable, usable, learn from it, and make it better This is what makes a Team happy, and people working in it satisfied and proud... or not?