Chaos is not Agile
While Agile encourages change and adaptability to better meet the current needs of the customer and the business, the sprint is a boundary that, when respected, protects the team from distractions and allows them to focus on getting things done productively. Protecting the sprint from excessive change provides the team with the stability and sense of direction they need to get things done. Often times people use Agile as an excuse for indecisiveness but if you’re constantly changing direction you’ll have difficulty getting anything done, and if you don’t get anything done then you’re not delivering any value to your customer. Read More...
When I first became a scrum master after being a developer, many people congratulated me on my promotion. I will confess that I was very confused by that response. I didn’t see scrum master as a ‘better’ job than being a developer, although I did see it as a job better suited to my particular skills and personality. I also hadn’t gotten a pay rise with my new role but I guess people assumed I had because career’s are commonly viewed as ladder. If I was changing my role, it makes sense that people would assume that I was stepping up another rung.
The Definition of Done defines what is needed to call changes made to the product ‘done’ or ‘complete’. It can be helpful to think of it as a checklist that needs to be checked off at the end of every iteration or for every backlog item. As a checklist, the Definition of Done helps us answer the question “How do we know when we’re finished?”
Best practice for scrum planning is to spend the second half breaking the stories down into tasks and putting hour estimates on these tasks. From these estimates a sprint burndown of hours remaining can be created. However, some teams view breaking stories into tasks as an unnecessary overhead. While there may be some cases where this is true, there are a huge number of potential benefits that come with breaking down stories into tasks so I would recommend teams at least experiment with it before writing it off as a waste of time. Below is a list of the potential benefits that will hopefully make it clearer why it’s worth spending the time.
Sprint reviews can be incredibly valuable opportunities to inspect and adapt but, if not done well, they can be viewed as an invasive blame-game, or a waste of time. At their best, reviews are an open and honest conversation about what changes have been completed, whether those changes deliver the business value that was hoped for and what changes need to be made next. It can be difficult to build the organizational relationships required to approach these reviews with the necessary trust and candor. Without these relationships it can be hard to dig out the underlying causes for disappointing business value delivery, as people will spend more time defending their mistakes, rather than learning from them. The focus needs to be on whether the customer’s needs have been met, not on who gets the blame if they’re not met.
There's a lot to learn when you first become a Scrum Master. Whether you were previously a project manager or part of the development team, you will find that Scrum Master comes with a completely new perspective. There's a lot to learn and, if you're doing it right, that learning process will never end. So what is the best way to start learning what you need to become a good Scrum Master? Here's some of my suggestions.
INSPECT
Questions
If you're ever unsure about what to do, a good place to start is by asking questions. As a scrum master I've found the questions you ask can have a much bigger impact than the answers you give. Often you can leave the answers for others to provide, but you get to be the catalyst by asking the questions that make people think about things critically.
Practice Active Listening by repeating what others say as a question to confirm their meaning. It can help you to develop your understanding in yourself and in others.
Active Observation
Observe everything around you. Try not to be a passive observer, but an active one. That doesn't mean interrupting or becoming a disruption. It does mean thinking about the underlying reasons for what's going on around you. Use the 5 Whys to understand not only what is happening, but why.
Learning
There are a lot of ways to learn about scrum in a way that isn't specific to your organization but should give you the information you need to apply scrum well.
Read lots. There are lots of books and websites about scrum so you'll never be short of new things to read.
Talk to other scrum masters. There are scrum communities out there, on scrum sites or on twitter and linkedin. You can also look for meet ups where you can meet other scrum masters in real life. Real life discussions can be the most valuable.
It's important to also learn about things other than scrum including a variety of development techniques and project management processes. Remember that everything you learn can be added to your tool belt. Then again, there's so much to learn you will need to prioritize. Focus on learning things that you can practice and apply practically in the near to medium term.
Ask for Feedback
Ask for feedback from others about how you're doing. Find people who you can trust to be honest. The scrum retrospective can be a good time to solicit this feedback from the team, but don't forget to get feedback from other members of the organization too. Ask them "Is there anything I can do to help you more?" or "What is one thing you think I could do better?"
ADAPT
Action Points
A good Scrum Master is one that gets things done. A good way to deal with this is to create action points at every meeting or as issues arise. The action points then become your personal backlog which you can prioritize and put all your efforts into completing them. Tracking what you've done can also help to motivate you as the done pile adds up. You can also review the done action points to reflect on which actions were the most valuable, which can help you identify and focus your efforts on more valuable actions in the future.
Experiment
Don't be afraid to try new things. Approaching changes as experiments can also help to get others on board. Put change in place for a sprint or two and then reflect on whether the change was successful and should be kept in place. If it doesn't work, do something else.
`Would you tell me, please, which way I ought to go from here?'
`That depends a good deal on where you want to get to,' said the Cat.
- Alice in Wonderland by Lewis Carroll
Just like Alice, we need to know where we want to end up in order to decide which way to go now. Having a long term plan can guide Product Owners when they're determining what we need to be working on now and help everyone understand why projects are important. A bigger picture gives context and links projects and stories together into a cohesive whole. One of the major criticisms of scrum is that it can put too much focus on the short-term and cause organizations to lose sight of bigger goals. However keep reading because I don't believe such myopia is inherent in scrum, but merely another pitfall to avoid and be dealt with.
In preparing for battle I have always found that plans are useless, but planning is indispensable.
-- Dwight D. Eisenhower
If you have already thought about possibilities makes it easier to identify your options and react to changing circumstances and emergencies. Long term planning can also make it obvious that you either need to compromise on how much you're expecting or start resourcing and organizational plans to ramp up capabilities. Hiring, purchasing and acquiring can all be time consuming so often need to be initiated ahead of when they are needed.
Problems with having a long term plan.
The main problem with long term plans occurs when people start confusing them with guarantees. People make other commitments (especially commercial, sales and marketing in a development environment) based on the long term plan and don't consider where they will be if reality sets in and date projections turn out to be inaccurate. Then they cling stubbornly to the plan even when it is becomes obvious that it is no longer relevant.
Another problem relates to the amount of detail in the long term plan. If there is too much detail there will be a lot of wasted time spent creating it and then updating it when changes occur, as they inevitably will. The trick is to get the balance between just enough long term planning to know where you're going but not so much that you're wasting significant time on planning and communicating changes. With either no long term plan, or a too detailed long term plan, you risk confusing people so much that they don't know where they stand.
Long Term Planning Solutions
A nice way to combine agile and long term plans is to have a backlog of what I call "super-epics". Super-epics represent the big goals of the organization and should be estimated with a different scale, possibly something like t-shirt sizes. Decide what is a realistic amount of t-shirt sizes to achieve in a year, or possibly in a quarter. You can estimate previously completed epics to help determine the likely super-epic velocity and refine this velocity over time the same as you would for a scrum team. From this you can estimate when these bigger goals are likely to be worked on and provide this information as your long term plan. Essentially it's the same as running Scrum but from a greater height. As you are viewing things from a greater height, these super-epics won't have a lot of detail until they are close to being implemented and are broken down into regular epics and user stories.
It's important that progress on the super-epic backlog is regularly reviewed. The organization can run equivalents to the three scrum meetings at this higher level. Planning to decide what work will be attempted in the upcoming year or quarter. A review to see what work has been completed and a retrospective to learn how things can be improved at an organizational level. It will likely also be necessary to review the long term plan more regularly, even every sprint, to see if it is still relevant given team progress and any new opportunities that have arisen. This is best done with reps from every area of the organization so that any changes that are decided upon can be clearly communicated and made with full information. Making changes to the long term plan allows the consequences and opportunity costs of decisions can be more fully understood.
To avoid people making commitments based on uncertain long term plans, keep dates vague for far out items. Start with the year then the quarter then the month, only clarifying the date when the unknowns are reduced along with the risks. Don't give in to pressure to be more accurate that you can truthfully be. Talk about target dates instead of release dates. It's amazing the difference a small vocabulary change can make to communicating more clearly.
A trap that many fall into when it comes to inspecting and adapting is only talking about what could be done and not taking the next step to decide what will be done. Talk is cheap, actions points can help to put your money where your mouth is. Here are 10 ways to make sure action points get actioned.
1. Record Action Points
It's not enough to just say you're going to do something. Really commit by writing it down and recording it. Action Points can be written as a list or written on post-it notes. The main thing is that they are recorded and not lost.
2. Clear and Concise Action Points
Express the action points in as few words as possible. This will make them more memorable and hence more likely to be done. If writing on post-it notes it will mean you can write bigger, which will make the action more visible. In a list, if each action point is concise then the list will be shorter and this will increase the chance of people reading through it. It's important, however, that you don't make the action point so concise that it no longer makes sense or misses critical information. Think about the next time you're going to read the action point - are you sure you'll still remember what it was about?
3. Actionable Action Points
Remember that action points are an action, not a problem or an output. An action point should address a problem and an action point should usually have an output in mind (and possibly even recorded with the action point) but the key thing to record is what needs to be done. A good way to ensure your action point is actionable is to make sure it includes a verb.
4. Completable Action Points
Like with user stories, it should be clear when an action point is done. Is a single action enough or does it need to be followed up until a certain result is achieved? This should be clear right from when the action point is written. Action points that sit around for months, with no-one really being clear whether they are done, don't help anyone. If an action point seems too big to be concisely recorded you may want to consider breaking it down into smaller pieces. What is the very next action that needs to be completed to get things moving? In this case you just need to make sure that a recorded output of the action point is that the next action is reassessed.
5. Action Point Ownership
Make someone responsible for ensuring that the action point is completed. In some cases this might not be the person doing the actual work, but the person who will follow up and report back on progress. This person will also be responsible for triggering any follow on actions and either dealing with or raising any blockers that arise related to the action point. Ideally the person who is assigned the action point will be present when the action point is created so that they have a full understanding of why it was created and they agree to actively own it.
6. Action Point Timeframe
It's helpful for everyone if the expected timeframe for the completion of the action point is clear from the start. It helps the owner know how urgently they need to get onto it and it helps others know when they can expect results. As a scrum master this can help indicate whether you need to chase up or offer help to the action point owner.
7. Visible Action Points
Action points have the greatest chance of getting done if they are constantly visible to everyone. If action points are visible then owners are more likely to remember to do them. My personal preference is as post-its in a special lane at the bottom of the scrum board. But the main thing is that everyone can see how many action points are pending, who is responsible for them (and which ones they are responsible for) and whether they are moving.
8. Review Action Point Progress Regularly
Action point progress should be reviewed regularly. How regularly will depend on what the action points relate to. Any action points from the retrospective could be reviewed at the next retrospective or even at the daily stand up if they were indicated as more urgent. Regularly reviewing action points will help identify if there are things getting in the way of their completion. It is important to deal with these action point blockers. If the owner doesn't have the time or skills to complete it after all, then ownership needs to be transferred elsewhere. If additional resources are needed to complete If circumstances have changed and the action point is no longer relevant, then it should be removed. (Be careful not to use this as an excuse to avoid things that are 'too hard' though!)
9. Valuable Action Points
Be careful not to go too action point crazy. People still have work to do and working on action points can get in the way so you need to make sure that action points are valuable so that their time is used effectively. Another reason not to have too many action points is that is dilutes focus and makes action points less visible in the crowd. Limit yourself to actioning items for the most important issues. Prioritize action points and identify where the most value can be obtained.
10. Review Results
For many action points it may not be immediately apparent whether the action has truly resolved the original issue. The action is probably an implementation of the team's predicted solution. In this case it can be good to keep the action point in a holding bay and at a later point in time review whether the intended benefits were actually achieved. This can help you to reflect on whether your action points are generally well-formed and perhaps guide you on how to improve your action points for the future. If the action point hasn't delivered the desired results you may want to consider whether the issue requires further action.
Story points are supposed to be an abstract value based on their relative complexity when compared to other stories. However developers, with their detail-oriented minds, often fall into the trap of aligning story points with hours. There's a couple of reasons why this isn't an ideal situation which I'll explain and then I'll talk about a couple of techniques to get them back
Why it's a bad idea
As well as being useful to predict when groups of features will be complete, velocity is also useful as a measure of effectiveness. If you are inspecting and adapting it is expected that your velocity will increase over time. The problem with aligning story points with hours is that a sprint has a set number of hours inside it. If two weeks is equivalent to 20 points, then a two week sprint will always be 20 points. You'll lose the ability to use velocity as a measure whether your team's effectiveness is improving or deteriorating. Information like that is too valuable to just throw away.
The second reason for not aligning story points with hours is that it's actually less accurate. Many people are surprised by this. They think that if they can think of all the tasks that need doing with all the details they'll then be able to work out an accurate time estimate. Unfortunately, creative and complex work like software development doesn't work like that. There are almost always tasks that won't be thought of, unexpected questions and decisions that won't come up until the work is started. Luckily, these unknowns are distributed across stories based on their complexity. So if we estimate using relative complexity, our estimates will be more accurate.
Humans are much better at estimating relative sizes than the absolute anyway. As an example let's say that I asked you to estimate the height of the tallest building in this picture. I bet you barely know where to start. Some of you might have started trying to count floors, but you just don't know enough detail to even get that right. If I asked a group of people to estimate it, there would be a huge range of values with very low precision. However if I told you the height of any of the buildings around it the accuracy and precision would immediately improve. We call this a yardstick value. A value which other items can be relatively measured against.
If we return to user stories, it doesn't matter if the yardstick value that I gave you is 'wrong' because it's a relative value. In fact it can't be wrong. We'll be measuring our velocity according to this relative yardstick so the system is self-sustaining. If we equate story points to time though, then it would be possible for the yardstick to be wrong, which is why we need to be so careful not to do that.
Once we have the relative size we can use our historical velocity in story points to determine the approximate length in sprints of a release made up of user stories. Of course it's important to remember that no matter what, estimates are still estimates. If they were always 100% accurate we wouldn't call them estimates, we'd call them measurements.
Techniques to avoid time based estimates
1. Make sure you've explained to the developers everything above so that they understand the theory behind things. Developers aren't stupid, they can correct their own behavior if they understand why.
2. Have yardstick stories from previous sprints available and visible to everyone in the team. If you have no previous sprints then compare it to other previously estimated stories. You can ask questions like "do you think it's bigger than Story A" or "is it about twice as complex as Story B?" to get team members thinking about things in relative terms. In time they'll start doing it themselves.
3. Instead of starting with story points, start by ordering the stories in order of complexity. This can also be a good way to get started with story points. Once you have the stories laid out in this order it's just a matter of putting the points along side them as a scale. This can also be a good way to get points across a large group of stories at once.
Once a company's scrum implementation reaches a certain size it becomes necessary for there to be multiple Scrum Masters. Even more necessary is that these Scrum Masters work together as a cohesive team. As is often the case, the sum is greater than the individual parts and a functioning Scrum Master team can have a major impact on the business.
When Scrum Masters work separately without syncing up you put yourself at risk of contradicting each other and making plans that are completely at odds with each other. You might assume that because all Scrum Masters are working to the Scrum Guide that there would be no risk of contradiction. But if you've read much Scrum literature (especially on the internet) then you know that interpretations can vary greatly, in addition to the fact that the Scrum Guide doesn't delve greatly into details and every company has different issues to be dealt with in different social contexts. This is one reason why it's crucial that Scrum Masters work together, so they don't cancel each other out and dampen each other's effectiveness.
Regardless of the issues that can be caused by Scrum Masters not working in line with each other, it is still beneficial for Scrum Masters to work together. Two minds are greater than one and conferring with each other on the issues you face can often help to develop even better approaches than one Scrum Master could have come up with alone. I especially like to share the approaches I've decided won't work with my fellow Scrum Master. She can often help me to find a way to adapt my idea and make it work after all.
Sometimes you require a 2 pronged attack on a particular issue. For good cop, bad cop scenarios for example. Every Scrum Master has different social relationships with each member of your organization. Sometimes you can be too close to your team to be objective, or too close for them to listen to you. In both cases the outside opinion of another Scrum Master can do wonders.
I have found the best way for Scrum Masters to keep in sync with each other is to have regular catch-ups or stand ups. These could be daily or every few days depending on how much overlap there is between your teams and how close they are within the bigger scheme of the organization. Some people may think that the Scrum of Scrums is the time for this but I don't agree. Firstly, I prefer the Scrum of Scrums to be primarily driven by team members as opposed to Scrum Masters - team members know best about the issues they're facing. Secondly, Scrum Masters usually have a broader view that just the team's current work, which is the focus of the Scrum of Scrums - remember, there's a whole section in the Scrum Guide dedicated to how the Scrum Master should serve the organization (and not just the team).
Just like the team stand ups it can be good to have something to keep things focused and for the Scrum Master stand up I recommend an Impediments board. This is a basic kanban/scrum board but with a prioritized list of impediments instead of user stories. The Scrum Masters can then work to break out tasks to deal with these impediments and then allocate the tasks amongst themselves. Doing things this way can help to avoid duplication of effort when there are common issues across teams, as well as making it more obvious which issues are these wide-spread ones. Impediments should also be dated so that it's obvious which ones are not progressing towards resolution - these are the impediments that either need the most focus, or need to be reassessed as to their importance.
An Impediments board can also be good for team members to view. They may feel relieved to see that the Scrum Masters are across the issues they are worrying about or they may be able to suggest things that the Scrum Masters have missed. Finally, as things move across it can help everyone to feel a sense of progress. Often we become so focused on the issues at hand that it can be easy to forget how much we have improved already and how much we have achieved.
When it comes to enacting organizational change there are two main approaches: Evolution and Revolution.
Evolution involves smaller, gradual changes constantly over time while revolution involves larger changes at a fast pace. In truth it doesn't have to be one or another as it is more of a scale with revolution and evolution at opposite ends.
Some people prefer revolution because the results are more immediately obvious, but revolution can come with a cost. Revolution can cause a big disruption and distract people from the work at hand. You also have a lot less control when big changes are happening quickly.
However there are times when revolution is necessary. Sometimes evolution is too slow, especially in times of crisis.If there has not been much change for a long time the organization may be suffering from inertia and the team members may not be open to change. In this case revolution can provide the shake up that's needed to get things moving again. Other times revolution can actually be less disruptive than evolution in the long run and you just need to pull the plaster off quickly to get it over and done with.
If you are always relying on revolution it could be a sign that you are being too static the rest of the time. Remember that it is the Scrum Master's job to make sure continuous improvement is ongoing and take an active role in making sure that this happens.
There are times when you need to be especially weary of revolution. If you staff are stressed out from a lot of previous change it may be that you need to give them a chance to catch their breath and recover. If you staff are burnt out you need to ensure that the benefits of any change are positive and obvious so that the change doesn't cause them more stress and push them over the edge. In general you should compare the risk of revolutionary change to the cost of letting the dysfunction remain for a given amount of time.
Either way, you need to make a choice about how changes occur in your organization because the only thing that is constant is change. Will you control your changes or be a victim to them? The decision over the mix of evolutionary and revolutionary change to apply at any one time is something that needs to be continuously monitored and evolutionary change needs to be constantly driven. While evolutionary change requires an organisation wide effort, the scrum master can be the catalyst. Revolutionary change often requires a crisis as a catalyst where evolutionary change can help you to avoid the crisis.
romaincrisis
annaxmalina
stormborns
andulkaphoto
kianamaiart
prguitarman
titsay
dailybridgerton
dededos