Posts Tagged SCRUM
Before everything else, getting ready is the secret of success.
Many of us doing Agile do not understand that it is primarily business mindset, rather than just another methodology to deliver software. Balance and sustainability of constructive conflict (key driver of any prosperous business) is the secret sauce to implement Agile successfully.
Let me explain it from practical business perspective. I will drift away from IT and software now…
Imagine you’re running business delivering…. car repair services to your customers.
It is your interest to deliver services fast and having quality in, so that you retain your customers and attract more (as it’s known that satisfied customer may bring 1 or 2 others, while dissatisfied one may stop other 8 coming to you). On one hand the more services you deliver, the more money you get, so you will push for more. But if you start pushing harder than your team is capable of, your service quality will start to suffer and this will obviously cause problems with your customers.
So you will try to get as much as possible given your conditions, while keeping quality in.
Now let us look at it from your customers perspective…
They want to have their car repaired cheap, fast with quality in. When you say your’re busy this week and cannot take their car, they will consider someone else’s services, rather then agree waiting that log (reality of market competition);
So, there is conflict of interests and mismatch between demand and offer.
It drives 2 things:
- Your business development (we need to improve our service to deliver faster/more/cheaper);
- Your customer’s expectations (maybe these repairs are not doable that fast/that much/that cheap);
Two consequences out of that:
- When there is no demand, why should you care to do more/faster/cheaper?
- When there is no chance to change your customers expectations either you’re doing poor job or your customer won’t likely get any better services with reasonable price anywhere else (task for your client managers to drive customer’s expectations).
So mismatch of those two creates conflict of interests that drives change.
The art is to understand to what extent you’re capable to improve things at your business given your current circumstances, while managing your customers expectations in the way to have control over gap between your offer and your customer’s demand.
Controlling this implies another important thing: ability to recognize challenge that you will fail taking (you should constructively resist) and challenge you’re able to overcome (and should take) to improve and continue managing “the gap”.
If you do not understand this you will end up bad. Either you will not be able to deliver quality in to your customers or you will be “beaten” by your competitors. In both cases you will end up being out of business :(.
Now let’s come back from cars to software and Agile
Customer is Product Owner (PO), while your business is your development team. The more you think business-wise and consider your team a business the better your team will be satisfying your PO.
So it is as easy as managing just 2 things:
- Your PO’s expectations;
- You development (quality and predictability);
Agile is just business common-sense mindset, nothing else! So to implement it right start from considering that you run a business in a highly competitive market with goal to satisfy your customer.
And mind that there is difference between pleasing and satisfying your customer, so argue, stand for your point, do not let compromise quality, do never over-commit, protect your ability to deliver, manage expectations, and … satisfy. If you do not follow these simple business rules and will focus on just pleasing your customer (or PO) just as in business you will end up not being able to manage what you’re responsible for – QUALITY.
Good Luck 🙂
Many Agile coaches have their own list of top failure modes. My favorite one is Mike Cohn’s: “How To Fail With Agile: Twenty Tips to Help You Avoid Success“.
But I also want to publish my winning list of things that impact teams and undermine their trust in business and Agile (combined from experience gained observing different teams at different times, so no particular team is meant here 🙂 ).
So tips are written from the Product Owner perspective:
1. Argue in front of team at Sprint Planning. Let them see you were not capable to decide what you want to build them. Moreover, involve them into arguing. This will demonstrate how your (PO) team misses integrity;
2. Demonstrate that being on time does not matter: interrupt meetings with calls, side talks and questions. Leave the room occasionally and be late regularly. Doing this will make it almost impossible to demand on-time delivery from the team;
3. Continuously fail to deliver INVEST stories and integrity in sprint goal/product backlog. Let stories w/o details thought through, so that team feels you had not invest enough time to prepare them. This will also make it easier for team to fail delivering outcome of that stories to you, will make things more ambiguous, so that no one will understand where is failure or what was wrong and will never learn from it, so that improvement will not be feasible;
4. Ignore team signals on complex stories (the ones that are above ~13 story-points, the ones that are risky, big, and usually need to be analyzed and split into smaller chunks in advance). Just let big stories that have big doubts, leading to easier underestimations, over-commitments, sprint failures, causing less team confidence, further under-commitments and wastes of all kinds;
5. Present deadlines ignoring reality “I do not care how you do it, it MUST be done”. With this “masculine” management style you can always push things forward as Agile teams just delivery chain, so they must obey and no matter what they think and capable of;
6. Never share the Product Vision and mid-long term roadmap with the team (just keep it secret);
7. Ignore technical debt (just concentrate on #5);
8. Bombard team with in-sprint questions and “Can you do it now please?” tasks. Explain them that SCRUM is good but now we need to be more “FLEXIBLE”. Moreover, assign tasks to team members without talking to entire team. Demonstrate that you were not been able to plan things for an iteration, this will ruin team trust that they are working on most valuable things and completely undermine their ability to deliver;
9. Never groom your backlog just leave it to the sprint planning meeting when it is already too late. This will lead to long and stressful discussions as you will have to do it mid-planning,will drain team energy, lead further to fatigue, wrong estimations, poor planning and sprint failure;
10. Always try to find something that team did wrong to pin point and focus on blaming. This is proper way to avoid Kaizen and let team protect themself by “storytelling”;
Scrum is based on “Empower the Team” Lean principle that prescribes self-organization. This means that regardless of age and experience team members are equal and serve as managers to one another. There is strong rationale behind: people that do the work are the best to manage it as they own responsibility of results and know best how to handle it.
Daily stand-up or daily SCRUM is a team tool to reflect on changing reality and adapt accordingly.
I’d like to point out some cases when self-organization does not work as should and help those teams out to boost their productivity.
Let us discover some sick stand-up/self-organization symptoms first…
1. Refraining from exposing problems (ignorance of reality):
- Task takes longer than planned and reasons are not clear to everyone (or something holds back people from raising problems);
- Task is blocked and impediment is not exposed/raised (this also may indicate some other problem with task that is not comfortable to raise);
- It’s just a way it is (yes we all know that we’ve planned 4 hours for that task, but as usual it takes us 2,3,5,… times longer or this guy always messes things up, we can do nothing, etc…);
- Team does not reflect during a day on changing reality (just in stand-ups), leading to impediments piling up and being addressed late, so that they mask something else;
2. Intolerance to critical feedback:
- Team member pushes back heavily when someone tries to rise a problem related to his/her task;
- Raising problems considered as de-motivating and team silently prefer to hide them until it’s too late;
- Team members prefer to stay “nice” to each other rather than constructively criticize their plan in order to adapt it daily;
Those two are inter-related. As a team member one will hold back from giving critical feedback if receives push back from his/her peer leading to confrontation and poor->no self-organization…
Scrum Masters, look around. Don’t you observe those symptoms during your stand-ups and/or during daily work?
If yes then…
Try out following cures ….
- Talk to push-backers one on one, try to understand what makes them do so? It could be personal issues with team members, lack of positive feedback or self-esteem, or other personal or inter-personal problem(s). It also could be absence of trust (readiness to look vulnerable to the team).
- Explain that feedback is not oriented towards person, rather towards team (exposes problem) as there are no personal problems in a team, since problem causes wastes, further slowness, incompleteness and later sprint failure of entire team.
- Focus person on constructiveness rather de-structiveness when exposing problem and coach on asking why 5 times, usually it helps to come up with adequate counter measures to remove root cause of the problem;
- Educate other team members that raising questions is crucial and needed, but highlight issues and offer them to try out different ways to do so (there may be personal barriers for push-backers, so more “gentle” way may be less stressful while lead to the same result, e.g. instead of asking “Why you did not finish this task so far”?, try “What holds you back from completing this task”?
- Cultivate more solution oriented then problem stating approach (as solution is vector, while problem is scalar);
- Talk to entire team that problems are normal and ignoring them just postpones failure. So they require courage to face and team spirit to overcome, that makes difference between team and group of people. Exposing problem does not mean it shall become energy-drainer and de-motivator, rather it’s in-time red flag that shall re-focus team on next right thing to do;
- If conflict is unavoidable and your peers do not go with “exposing problems approach”, steer it, but not let pile it up (nice article on conflict avoidance here);
- Launch team storming to “shorten the distance” between team members, so that exposing problems is more constructive and easy (see: “Teamleads, “Storming”, Self-organization and Entropy”)
- Propose and drive team branding activity to help them find out shared values and motivators (see: “Team DNA: how to Brand up your team”);
To summarize, work both ways with ones who raise (also including you if you are in SM role) and with ones who push back to make raising problems comfortable and easy.
“Problems cannot be solved by the same level of thinking that created them.” Albert Einstein.
I was about to write another one in the scope of “Getting them…” targeted for Product Owners (PO), however thought that before getting them (stories) out of the sprints it is crucial for sprint success how to get them (team members) on it right…
So story going to be about how PO influences team focus and instills feeling of urgency and what happens if he/she’s not…
To understand this we would need to get back to Sprint Planning meeting (SPM). When PO makes final accords, accepts team commitment and sends team out to the sprint it is very important for everyone to stay focused on the Goals PO presented.
If PO jumps in mid-sprint, having unplanned acceptance criteria, special circumstances, etc… this sends a message: goal is void, direction is being changed, things that had been agreed at SPM are not valid anymore.
Scrum is tense way of delivering software. Constructive tension comes from high commitment and builds up high velocity (aka deliver fast lean principle) that is impossible to achieve without addressing limited and fixed number of issues within timebox.
Let’s understand how this works…
Higher velocity is achieved by staying focused on what is most important. As soon as this vector changes, something that had been important yesterday, becomes less important today, or something else emerges focus drifts away.
But velocity is not single thing this impacts…
More drastic effect this has on team morale, since besides team has to conduct context-switch (that has it’s own impact: see another related post here), but also it throws team into “Less” vicious circle that is:
- Less focus that eats up energy and leads to …
- Less energy that impacts productivity and leads to …
- Less commitment that impacts desire to work and leads to…
- Less motivation that drain attention and lead to …
- Less focus …
- Etc …
Understanding this will help PO to plan sprints in the way to avoid de-focus, protect sprints from interference (and team members from de-focus) and minimize impact of unplanned issues.
Of course fire-fights happen, of course they are important, but it makes sense to dive in root causes and build real quality in rather than fight consequences… and eventually turn circle back into “More..” :).
I would like to start with describing what cycle user story goes through before it becomes READY for sprint planning meeting and how PO handles this cycle.
For sure there are many best practices to get stories READY and write proper stories. Instead of focusing on story-writing itself, here I will cover PO workflow to them ready.
So, here are my 5 cents…
Assumption: user stories are part of shaped big wish (called epic), that is part of Agile release/roadmap and takes place on “storymap” that had been presented to development team some time ago.
What does this means?
This would mean that:
- Value brought by an epic (and future user stories) is clear to everyone;
- Possible big “underwater” problems it may cause surfaced (reworks, performance, missing data, uncertainty, etc.);
- High level estimates are given to an epic;
- Big questions are addressed;
As next step PO prepares epic further, splits into particular stories, sizes each of them and “hones” acceptance criteria (aka satisfaction criteria). To proceed we need to know what does INVEST mean.
What is INVEST?
Things PO should keep in mind when doing story-writing and story-splitting is “INVEST” rule. It stands for:
- Immediately Actionable – so that team can start working on it immediately;
- Negotiable – so that can be quickly made smaller/bigger by removing/adding scope of acceptance criteria (AC);
- Valuable – so that everyone understands what value it brings to an end user;
- Estimable – so that it can be estimated with user story points or ideal hours;
- Sized to Fit In – so that estimates fit in established iteration length;
- Testable – so that has understandable and achievable acceptance criteria;
Splitting an epic
Then it comes to the split itself. I suggest doing the following way:
1. Have a pencil and paper talk with your PO peer(s) on the epic before splitting:
- define overall description (As a WHO I want WHAT so that WHY);
- agree on the way to reach WHAT (draft acceptance criteria, aka AC);
- write AC down. You will end up having many AC, e.g. 30 or more;
2. Request, get and provide stories with everything that makes them immediately actionable (e.g. designs, data, clarifications, everything that has to do with 3rd parties, etc.);
3. Define story split logic, so that they all can be worked on quite independently and placed in a sequence that satisfy following criteria:
- upper stories do not require functionality of lower stories (and lower stories do not impede implementation of upper stories);
- functionality is split logically, trying to keep stories ~same size (remember, best sizing of stories is 3-8 user story points);
- upper stories allow user to see maximum valued functionality first;
4. Define each story description and split overall AC accordingly. Keep in mind that at this point new stories will pop up (I call them “conjunction stories”). The rule is easy to understand.
Epic Box Principle: “As soon as you start emptying virtual box of epic functionality, removing and shaping story after story out of it, you will find out something that is still there and was not your initial plan”.
If your plan was to split epic into 4-5 stories, you may end up with 7-8 or so. That is one of the reasons that explains why usually epic level estimates are smaller than sum of estimates of all corresponding stories.
Important hint: do not hesitate to split as combining is way easier. Splitting is good exercise because enforces to think through value->solution again and discovers potentially hidden problems, functionality etc. Another effect of splitting bigger stories into smaller is reducing doubt (and therefore risks) team will have associated with big story. It turns afterwards into saving user-story-points…
Therefore, it’s way better to have detailed backlog rather then let team estimate their doubt wasting story points on your inability to think through solution and side functionality that may popup during implementation of bigger chunks.
Remember: as PO you are in charge of what team does next and need to have stories prepared accordingly.
5. Peer review all stories with your colleagues after you consider them as READY to see what is missing, question how each AC may be interpreted, best guess on possible estimation;
6. Re-do steps 2-5 until stories are INVEST and READY for sprint planning meeting (SPM);
To be continued … (“Getting them through sprint planning….”)
“Imagination is everything. It is the preview of life’s coming attractions”. Albert Einstein
An interesting thought came to me while thinking on how to bring in dynamics in story map to make it a tool that will help PO both in day-to-day work/tracking and overall release management.
Key benefits that will serve this are:
- A full picture of upcoming product being built (within scopes of upcoming releases);
- Transparency about features are being worked on now/coming soon;
- Highlighting what features are READY and DONE;
- Done row indicates stories that correspond to the functional areas of the product and are accepted by product owner in sprint review meeting(s), having story definition of DONE met.
- Areas row indicates key functional areas of the product as any story map has.
- Wip row indicates work-in-progress, e.g. stories that are part of the running sprint (that team committed upon);
- Ready row indicates stories that are ready to be presented to team according to definition of ready. PO moves stories in this row only if those compliant with INVEST rule;
- Pipeline row indicates all the stuff that is planned for the future. As you can see some stories are non-READY here for whatever reasons (not yet completed, or even bigger items (epics) that are not yet prepared for sprint planning and thus cannot be taken by development team);
NOTE: pipeline row can be splitted itself into several rows to indicate scope planned for releases.
This simple board will serve as Kanban-style board turned by 90 degrees CCW. You can always add rows that indicate whatever states your PO team will find beneficial. Such a board can be easily used by PO daily in managing both day-to-day focus on getting READY for upcoming sprint, while keeping an eye on overall priorities and backlog.
Here’s real-live example implemented:
“People like talking about people. Makes us feel superior. Makes us feel in control.
And sometimes, for some people, knowing some things makes them care.” [HouseMD #113]
As described in earlier post in “TEAM: 7 indispensable ingredients for Together Everyone Accomplishes More” one of the key elements of a strong team is Brand.
An idea to apply known brand-building practice to team management seemed to me interesting and made me write this blog post.
So I would like to cover a useful tool that can be applied to build up your team brand…
Team Brand is essential team motivator that cannot be given to the team (by company, management, money, etc.), it needs to be build inside, owned and maintained by the team. Actually this is type of “achievement” and “idea”-motivator for a Team (here cross-functional, self-organizing teams are meant, although practice is applicable for any team of small size).
In other words, Team Brand serves as an alignment on its core values/ways to achieve, inspires team by having strong and challenging core set, while distinguishes team among others.
Team brand may be built as any corporate brand starting from key cause or a purpose, moving from core through the benefits (qualities, values) to attributes (tools, norms) supporting and transmitting them.
Well, but an agile self-organizing team needs a hint to start thinking of themselves as a “company”, having a “brand”. A hint that envisions this mind shift would sound like: think of your TEAM as of an entrepreneurship and your collaboration as of an inspiring challenge! Imagine you’re running business with your peers (which is not that far away from reality, considering self-organized development team doing SCRUM).
- WHY are we here, what we want to achieve together, what is our core, our strongest believe and our purpose? Why do we exist as a TEAM? Which core value we all share?
- HOW we can make this happen? What principles (benefits, qualities) support this?
- WHAT we exactly will do (and will NOT tolerate) to support each of the key principles we’ve agreed upon that contribute to our purpose?
A tool I recommend to use at this step to create and maintain team DNA is known “Team Radar” retrospective facilitation activity (see “Agile Retrospectives: Making Good Teams Great” by Esther Derby and Diana Larsen for detailed explanation).
It simply suits best this exercise. Here it is used to gather data on team itself and perform self-assessment in the future.
An outcome applying this practice to an Agile self-organizing team may look like this:
As soon as agreed Team DNA is documented, printed out and placed in visible area (ideally at the team scrum board and/or also very usefull in retrospective room). This will serve as a point to refer/remind when choosing for right decision/action and will keep team motivated to comply everything they think, decide and do with their core.
But this “artifact” shall not be “curved in stone”. It’s living, since team is also living. So on and on reviewing it, team curves itself, making their brand stronger and more unique, by finding out deeper levels of their own common values, purposes, beliefs and means, achieving them.
The more team does so, the more it finds it’s own distinctive way doing things and becomes more distinguished (“branded”) and valued by managers, stakeholders, POs, etc…
Good teams that value the way they perform and look, care about this and move further finding out more challenging cores, supporting principles and norms.
Besides that it’s a funny collaborative action that contributes to team building.
Brand up your Team, guys 🙂
- “How to Build and Manage Your Brand (in sickness and in health)” ebook
- “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))” by Lyssa Adkins
- “Branding Governance: A Participatory Approach to the Brand Building Process” by Nicholas Ind and Rune Bjerke.
Roadmap planning is indispensable part of Agile project management that represents second level of 5 levels of agile planning that any team should somehow cover. As a best practice suggests it needs to be done by product owner every ~2-6 months, depending on the intensity of development.
This exercise makes sure that entire team understands direction, goals and vision of the product team, brings many benefits and speeds things up by creating shared clarity about future and maintains high focus on the “vector” PO gives.
Recently I’ve facilitated Roadmap planning session applying two techniques: planning poker and story map. For those who want to get details of both techniques I would recommend nice extract from Mike Cohn’s “Agile Estimating and Planning”: http://planningpoker.com/detail.html and this nice article at Jeff Pathon’s blog: http://www.agileproductdesign.com/blog/the_new_backlog.html.
It was both interesting and challenging, especially since we’ve never try this before. It was great success since resulted in having clear, estimated and planed Roadmap for product fist steps.
- To share product roadmap and vision;
- To make challenges and risks visible and clear and address them early;
- To make approximate measurement the minimum required scope of the release of the product;
- To predict possible release date range / manage product scope in the way to hit deadline;
- PO prepared items (user stories and/or themes) written on index cards (one per card);
- Items were grouped according to the story map (by corresponding key product functional areas);
- Key area titles were stick to the glass wall at our big conference room;
- Horizontal line was drawn to separate the first release content over the wall;
- Scrum team in one room for 2 days;
- PO presented key functional areas of the product being built, briefly describing what each area covers;
- PO started presenting item after item, sticking on the corresponding map column of the wall, given priority he had in mind.
- Team estimated item presented with planning poker.
- When estimations were too different we’ve allowed 1 or 2 rounds of re-evaluations. Well, we did not played exact poker, since we were interested in the approximate estimations, so we took averaged estimations (i.e. majority raised 5USP, some guys 8USP, 6 or 7 is taken as an average, more feeling-based);
- As soon as a column was complete discussion on required minimum scope of the release content started and PO moves some items below/above “scope line” (also considering estimations and best guessing for ROI).
- Moving on and on to the next product column and item after item of a story map;
As result of 2 days workshop we’ve manage to:
- Gain shared clarity about what needs to be done to get product LIVE;
- Identify biggest project risks and “hairy topics” with poker estimations (those had usually high estimates, more than 20 USP, clearly);
- Agree on next steps (to start with risky but must-to-have items first);
- Noticed dependencies among items and moved them up/down in the way to decrease them;
- Estimate roadmap and predict delivery dates range (we’ve ended up having kind of 500 USP);
- On the level of details where items represent Themes rather than a requirements or stories according to the cone of uncertainty estimations vary from 0.8 to 1.25x factor. On the requirement/story level they also vary from 0.85 to 1.15x. Considering this I took an average ratio, given the fact that some items were story sized, others were bigger (nice article that illustrates correlation between estimation accuracy and uncertainty from Agile101: http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/).
- This number together with average team/historical velocity gave an idea of the range required to get product out within agreed scope;
- Roadmap planning is a valuable and must to have regularly exercise;
- It is both interesting and motivating for team members;
- PO gains a lot of important insides about product that allows to manage release scope and prioritization to minimize risks and get to live ASAP;
- Teams are enabled to plan more than just in time architecture since bigger picture of the product becomes visible;
- It shall be done outside of a sprint to guarantee 100% clear mind and focus;
P.S.: * many thanks to my CPO, would be impossible without his preparation and buy-in.