April 23, 2009

Scrum Master & Team Training in Zagreb

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 a te...

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 a telecommunication company in Zagreb it has been another very interesting experience, and again we learned something together :-)

Negotiation is the key, talk to the Product Owner...

The 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

The 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

The 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!

The 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 ;-)

The 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

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?

 The team after the training, tired, happy and proud!

Thank you very much for the great experience!

Best ANdreaT

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.
blog comments powered by Disqus
Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.

Latest Posts

Jan Barnes joining agile42

Jan Barnes joining agile42 as an Agile coach in the Canada team

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.