The Scrum Alliance is accepting new applicants to become Certified Scrum Trainers (CST) and I’ve decided to throw my hat in the ring. If you would like to know why I am applying, please feel free to read my letter of intent.
Tobias Mayer has a post on the new CST application process, including a link to the full process description.
The saying, “you drank the Kool-Aid” may be a derisive way to say someone has been indoctrinated. Similar to a Borg-related “you will be assimilated“. Admitting to drinking the Kool-Aid seems synonymous with “going native“. I think it’s worse than that. It’s forever linked to the Guyana Tragedy for me and is tantamount to committing suicide.
The concept of dogfooding I understand and I am a fan. Both of the verbification of nouns and of using your own product. Just not of the words. Similar to not wanting to be a pig, I do not want to be a pig noshing on some dog food. Although pigs are smarter than chickens. Pigs must not have that sophisticated of a palette, I guess. I wouldn’t want to work in a dog food factory that practiced this, either.
I am a fan of brew making and like to go wine tasting at smaller places. It helps me understand the craft so that I may try to practice it myself. Understanding all the ingredients, the process and the taste sought after. I think the phrase is gaining some popularity and I am now blatantly advocating for its use. Let’s drink our own champagne!
Agile infiltrates an increasing amount of organizations. Changes in the jargon detect its influence. Phrases and words like “inspect and adapt”, “vertical slice”, “velocity”, and “collaborate” start getting batted around like volleyballs at a beach party. People ask questions in the serious tone of a late-night host discovering what is interesting about the guest: “What is the highest ranked item?”, “What are the acceptance criteria?”, “What does the team think?”. Zealots mutter incomprehensible phrases like “maximize the work not done” and “tracking actual hours worked is unnecessary”. People insist it takes a shift in mindset to understand, and yet we don’t sign up for loosing ours in the bargain. How should this be dealt with? Where to start?
Some current activities must be worthwhile. Utilizing these new Agile tools for working, the team can gain consensus on what those things are. It’s not that what we’re doing is under investigation like a new federal appointee. How can the team carry on the best of the organization while remaining willing to change that which does not work and moving on?
With the basics understood, one way may be through reflecting on what works right now. Retrospect and close out the old while opening up to the new. This may be intensive, as the scope of the session could be broad and wide.
What works well for the team? These are the team’s working agreements. What works in the process? Map out how ideas turn in to revenue with a value stream.
The best way to capture the information is with high visibility. Hung on the wall and written to be read across a room. While analyzing the information the team also looks for immediate improvements and prepares the way to embrace the new Agile culture.
Using a retrospective approach in this way helps the team build consensus through collaboration. Keep an active meeting objective visible, as well as an area to park off-topic suggestions and ideas. With the iterative approach of Agile the team can also safely begin transitioning away from traditional behaviors and courageously embracing this modern approach to software development.
Lately I’ve been reading about people lamenting unsuccessful adoptions of Scrum within organizations. Somehow, these entities survived before Scrum was introduced. They are not just going to fold because they have not done it right. They may choose to ignore some of the principles of Agile and continue to bring in revenue without coming all the way around.
So the Agile community has some advice. Make sure good technical practices are in place. Have motivated and skilled people in the trenches with the will to change. Make sure there is executive support. Use some assessment tool. There are other suggestions, these just come to mind immediately.
If the right ingredients are not present, people are encouraged to leave the organization, or the organization to get rid of the misfits. Coaches are encouraged not to engage with dysfunctional organizations, or to fire the client when they discover that the resistance is too great.
This leaves me feeling uncomfortable. What about those left behind in the wreckage of an implementation gone awry? Fear, stress and lies are still the modes of operation. There is no hiding from the authorities. The overhead of the process is overwhelming. People are worse off, thanks to the mangled introduction of Scrum. For many reasons including personal and macro-economical, people cannot just leave the situation.
What should be done to help them?
What is all this stuff?
Can we take a look at the Product Backlog? Does this backlog contain a long list of prioritized “stuff to do”? Does this list include defects, functional tasks and/or feature requests? What else? Does this list include everything? Are there more items in the backlog than we can see in one glance? Have we determined the business value in this “stuff” as a basis for stack-ranking these Product Backlog items? Can we estimate this “stuff” in terms of relative complexity and help with prioritization? In reality do we have multiple lists for the product being worked on simultaneously? I would guess if the Backlog exhibits any of these qualities the product suffers accordingly. Does it suffer? Don’t worry, we can sort this out.
Coherence
For some, transforming lists in to a Product Backlog of this stature appears daunting. Enthusiasm to just get it done may ignite a desire to take it on all-at-once. Through the application of some workshops to shape and strengthen the backlog followed with check ups at regular intervals, the highest priority needs of the product should be well understood by all while team members remain friendly with each other.
Step-wise refinement
AKA Inspect and adapt. AKA kaizen. AKA iterate and increment. We can apply it as well to the effort of keeping the backlog in shape. Starting with what we have let’s sharpen it up a little, evaluate it against the running and tested features, step back and take a look at what we need and tune the backlog a little more. Take breaks to help keep the energy up, and the perspective fresh.
Who should we involve in this?
If possible, the whole team and the customer who will use the product and led by a single Product Owner. The team may be large, customers busy and the users many. Representatives from every role involved in definition, analysis and design come together to shape the backlog in these instances. Led by Product Management, common roles for the Product Ownership Team include Business Analysis, User Experience, Technical Publications, Software Engineering, Quality Assurance and Customer Support. The people involved should include those who can represent Product Ownership for the Scrum teams involved. The team should be broad enough to ensure a shared understanding by everyone of why we make what for whom. This team should be small enough to maintain consensus and get things done in a collaborative manner.
How important is it?
Everything captured in these lists are important, or should be removed. What critical needs should the system provide to the market, customers and users? Leaving some in vague terms is all right. What objectives do we satisfy and what outcomes are we looking for in a release? Write these up in a largely visible way for everyone to see.
How many items do we have?
If there are more than 3 or 4 Sprint’s worth of items on the backlog, we can walk through the backlog and prioritize based on the visible goals. Anything that can be easily agreed to as necessary calls attention to why they are valuable. It may necessitate adding to, or modifying the goals as well. Along with breaks keep sorting and look to see if about twenty percent, and/or enough for about three Sprints, of the items have bubbled to the top. Along with the visible objectives and outcomes, this will help ensure we concentrate the rest of our efforts on the things we need to work on now.
What do we have?
Let’s determine what types of “stuff” dwell in these lists of requirements. Could there be features, system specifications, use cases, tasks, defects, change requests and other errata? Does anything answer to the format of a User Story? Could it be considered a good one? Does the story have any acceptance criteria attached to it? At the end of these exercises, the backlog items should be identified by type. Characteristics of good User Stories have been discussed and examples are now identified. The teams start to have a better understanding of what is being created to fit the domain.
What’s it worth?
Starting with the first item, the team should discuss how this may fit in to a User Story. If there are items identified as User Stories, check for clarity what makes that the case and refine as necessary. The story may need some rephrasing, split if complex, or combined with others if not really valuable. Capture as acceptance tests the confirmation agreed upon as the scope and value of this user story.
Features and change requests are close to user stories. Once a couple of user stories have been discussed these are easy to reformat to fit the template. If it is not a user story, it could be part of acceptance criteria of one. Use cases and tasks are likely candidates. Otherwise, it may be a non-functional requirement or a constraint of the system. These are likely found within the tasks listed. Defects encountered should have the actual and expected outcomes recorded. This helps make sure they are not really change requests. If they are enhancement or change requests, it is easy to rewrite as User Stories.
What else needs to happen?
Now that the backlog format contains User Stories we can estimate relative complexity with Planning Poker. Look for the themes that the User Stories belong to, and identify Epics and Spikes. Keep the non-functional system constraints visible. We can turn it in to a Backlog Map, AKA Story Wall, to help prioritize and discern viable releases. Mid-Sprint pre-planning meetings will keep the backlog in shape, ensuring there remains 3-4 Sprints’ worth of Stories and well-understood acceptance criteria.
Is that all?
Keeping the backlog in shape with well-sized User Stories and acceptance criteria is an ongoing process continuing for the life of the Product using routine collaboration sessions, design workshops and Planning Poker. This is the input in to the system and Sprints will only go as well as the shape of the Product Backlog.
I recently received an email from a senior-level manager, who raises a valid question about all the meetings associated with Scrum. This particular instance of Scrum has over 50 people working in more than one locale. When yet another meeting was created, he raised a valid question:
90 minutes every week for backlog hygiene? And that is on top of all other scrums, scrum of scrums, business reviews, can we ship, planning etc. meetings and scrums? I am getting seriously concerned about our state and efficiency. If we need to spend 90 minutes on this weekly, than, IMHO, someone is not doing their job. Looking forward to find out more.
My answer:
It’s true, this is a lot of time to spend together planning what we are building for this product. Are you familiar with the book, “Death by Meeting“? Essentially, a short daily meeting (15 minute standup) should focus on the daily plan (3 questions). The longer the meeting, the further out we’re looking. Meetings should have a very specific purpose, stick to it, start on time and finish when the purpose is reached. In Scrum, all meetings are finished when they hit the time-boundary (aka time box) as well. We endeavor to reach the objective before hitting the time boundary. Scrum-of-Scrums (SoS) is a little exceptional as you’ll see.
Let’s look at all the meetings in our Scrum.
-Daily stand-up. 15 minutes max. Only pigs are allowed to speak.
Single team daily coordination. Answer 3 questions.
1. What did I complete yesterday?
2. What am I planning on completing today?
3. What’s in my way of completing work?
We stand up to keep it short.
http://aaron.sanders.name/agile/what-if-the-standup-is-ended-on-time-but-not-everyone-spoke-Daily SoS. Meta-stand-up. Inter-team coordination.
First, answer 4 questions. 15 minutes max and again, only pigs are allowed to speak for this part.
Scrum Master and Product Owner for each team required, other team members are optional as needed and/or interested.
1. What did our team accomplish yesterday?
2. What is our team going to accomplish today?
3. What is in our team’s way?
4. What are we about to put in another team’s way?
Then, we review all the obstacles on the board. Reporter confirms removal of existing ones. Decide how to remove the ones added today. Old obstacles are scrutinized.
Last, we walk through the Air Traffic Control (ATC) board and ensure it reflects reality. If a problem is detected, a plan is set to address it.
This meeting is the only one without a time boundary. We stay in the room until all goals of the meeting have been addressed.-Weekly backlog hygiene
Keep the backlog in front of the Scrum teams by 4-6 weeks (2-3 Sprints).
+ Review meeting agenda and ask if any item for end
+ Review customer and user input about the Product
+ Review arrangement of the stories in themes and goals.
+ Write new stories, themes and goals. Remove old and wrong ones.
+ Review and update acceptance criteria currently known.
+ Prioritization
+ Team added agenda item, wrap-up.
Add new stories, keep the top prioritized. Look at the bigger backlog map. This will become the release planning mechanism. 90 minutes does seem long right now. Prioritization is not an easy endeavor. I would also like to enhance understanding of the User Story and examine the ones being added together. Some are coming in from user interviews. More are likely with Customer Support involvement. There are some interviewing-like ways to create them, so that eventually the customer/user can write them for us themselves. The time will also be needed later, once the teams pick up value delivery. All of this will intensify to stay in front of the progress we make.-Review and Retrospective (aka Reflection)
Every 2 weeks we review the current working software with the customer, showing User Stories the Product Owners have accepted on their behalf. We then ask *them*, can we ship this to you? The answer will influence the backlog, too. The teams then gather and go through a retrospective to ask themselves, how did those last 2 weeks go and what would we like to change and experiment with to find improvements and innovation?-Planning
We are now planning as we go at many different levels, so that is much less disruptive to the teams. For the pigs involved who are busy creating value, it is an impact of 15 minutes daily, and 2-4 hours for one day every couple of weeks. We are meeting so that they can continue to do their job of creating the actual Product.-and more!
There should also be monthly meetings to look at the next 3 months, and quarterly meetings to look at the next 4 quarters, and yearly meetings to look at the next 3 years. That last one may be a 2-3 day off site.http://leansoftwareengineering.com/2007/11/14/planning-a-month-or-less-ahead-is-not-enough/
This is a complex, adaptive system with emergent properties. The system is continuously running at a sustainable pace, with value flowing through it from concept to cash. We need constant feedback so that we may inspect this system and ensure we are adapting to the best of the emergent capabilities. The concepts are captured as User Stories, and when we release it we determine the market value, when we start getting revenue from the Product. Along the way we keep our customer/user involved at every step and invite them to attend any meeting. Except the Retrospective, which is for the pigs.
The ATC board shows all stories in progress for all teams. It includes the top of the backlog in a stack-rank buffer for teams to accept work from when they have delivered something and have capacity (below the story point WIP limit).
There are more than the 4 meetings mentioned in the book: stand up, SoS, review, retrospective, can we ship?, planning, backlog hygiene. The longer-term Agile strategic meeting is not yet in place. How else should I address the concern? Is there too much mixing up of strategic goals in the weekly tactical backlog hygiene meeting? Should that be pulled out to the monthly strategic meeting? What should be in the tactical one, then? What could be removed from a meeting, or a meeting itself? How would you redo these to be more effective?
After a few months working with a client, a WIP limit was introduced on story points at the latest planning meeting. When we started I said, “The good news is, you no longer need to track hours remaining. The better news is that you may never have to have this type of meeting again.” Here’s a nearly verbatim email from senior management, after planning.
We concluded the sprint planning today with a stack ranked backlog based on work folks did over the last couple of days (to get it prioritized). The sprint planning went well, all teams are “fully loaded” for the sprint except for Team-1. Here are my observations, anyone on this thread, please feel free to pitch in:
Team-1 was at ~(x) points, and the max per sprint is (y), so they could have taken more user stories. We went down the backlog and the next 6 or 7 required [special-skilled work only a couple people can do and they were] already maxed out (…) for this sprint. Further down the backlog were [feature groups for another team] related stories and since [those feature group] teams were max’ed out, we just stopped.
So, does this mean that Team-1, once done with their user stories, are going to start twiddling their thumbs? Maybe, but first, they HAVE to help other teams:
- with tasks
- with user stories
- help QA in testing to get the stories to the done state
- remove blockers from the blocker board (and we have identified new blockers that are slowing us down per the retrospectives)
- and basically help in any way shape or form move the stories on the board to the done state.
If all of the above is exhausted and there is really nothing else that Team-1 can do to help the current “in-flight” user stories across teams get to the done state, then, yes, they will be twiddling their thumbs and we would have identified a blocker that we need to address. Otherwise, we continue to push forward.
Do you think the new WIP constraint and attitude will help? Will there be an increase velocity and in quality of delivery, in your opinion? How about the effect on sustainable pace, or collaboration? Please comment below and I’ll provide my own opinions in following posts.
If you track them electronically, some of the process changes, as many APLM tools allow for issue tracking. Hopefully, the intent and result still make sense.
Blocker Board
Always preferring high-touch and visible information radiators to track items, I tend to make a physical blocker board for teams I work with. Why do I call it a “Blocker Board”? It alliterates. I am finding it to be a problem to call it this. Perhaps I should change it to an “Obstacle Catcher”, or something that doesn’t make people think the sky is falling, just that we’re hunting for the system constraint.
Reviewing obstacles
Hopefully the obstacles are being removed quickly, and reviewing all obstacles identified during stand up lets the team verify the ones which have been removed. Having the requestor on the card lets that person verify the obstacle is gone. For the new one’s added, adding the day’s date, lets the team understand how long it took to remove, when verifying with the requestor. This review also gives a moment for people to think if they know (or want to admit to) another obstacle in the team’s way.
Obstacles are non-debatable
Having a working agreement that nobody can debate when someone states the fact they know of an obstacle helps ensure people feel comfortable bringing things up. If it is pushed off as, “not really an obstacle” or, “not an obstacle yet” can be very deflating to someone and cause them to resent mentioning it. Even if the requestor does convince others and writes it up, they may feel apprehensive that it will truly be removed.
Obstacles must be removed immediately
Having another working agreement that everyone should endeavor to get obstacles out of the way immediately, helps the morale of the team. Obviously, this allows the team to be as productive as possible. Removing obstacles immediately builds trust within the team and with management, increasing the camaraderie and expanding the notion of who is on the team. Immediate removal motivates the team, increasing respect by dealing with issues brought forth, without questions asked.
Avoid assigning owners and due-dates
Some obstacles take some time to be removed, even when endeavoring to have them gone by the next day. Assigning owners and due dates is a threatening stance. This is doubly true if obstacles are shot down as really existing when initially mentioned. Assigning one owner, especially at stand up in front of the team, implicit blame is laid on this person for having a problem. The date can only be a guess, and is now given under duress, if it is also in front of everyone. Date assignment allows the person to procrastinate on it, or use it as political leverage. It is stating that the team is fine allowing an obstacle to exist, and slow down the system. For political leverage, it is saying that I will not remove this obstacle, until you do something on my behalf. With the date being a guess, what happens when it comes up and the obstacle is still around? How much are you allowing someone to “game the system”? Assigning owner and due-date erode the sense of team and of collaboration. Avoid this, no matter how much you may feel it is the right thing to do.
If all else fails, prioritize obstacles
When the rate of obstacle removal is less than the rate of obstacle identification, there is yet another obstacle in the way. It might be incredibly difficult to find. In the mean time, prioritizing the ones that are identified helps find the greatest one for the most people. This may be close to, or a symptom of, the system constraint.
Finding the system constraint
Somewhere in the system, there is a very large obstacle, causing a bottleneck that could potentially be jeopardizing success, destroying morale and causing most of the stress. This is the team’s most significant impediment. This constricted area is the system constraint, and is where work passes through at the slowest rate. Having the practice in place of including the date added shows which ones have been around the longest, pointing the way. Agreeing to remove them immediately adds to the significance of obstacles that won’t go away. Prioritizing obstacles will also help identify symptoms of this constraint, and maybe even the constraint itself. Adding the requestor allows the organization to recognize the person who found this constraint, and reward them along with those who removed it, for helping to bring the team to a greater level of performance.
Removing the system constraint
Theory of Constraints explains it thus:
Eventually, the largest obstacle which cannot be removed is found. Keeping this part of the system on a regular cadence and knowing it cannot go faster, makes it the heartbeat of the organization.
When a client asks me about what tool I would recommend for tracking backlog items, I return with a question of my own. How distributed is the team? I should also point out that my definition of distributed means outside of one open, shared work space area and includes working from home.
If the answer approaches that they’re 1/2 way around the world, then I find out if the remote team can implement stories on their own. I also probe to see if there is any sort of remote proxy for the Scrum roles of Product Owner and Scrum Master. If the team can only work on one component, or perform limited functions, then I answer along the following lines:
I like sticky notes on a wheeled whiteboard. Let’s ensure this high-touch board is in place. An electronic instance is needed when the team is highly distributed to persist what is going on with the physical board. We can identify what tool best captures this data for your context, or modify the one in place to suit these purposes.
It would be best to get the remote folks together for Sprint planning and reflection. Let’s have a representative on each local team for the remote group. This proxy for the remote team will also be responsible for the local team writing the tasks on to sticky notes needed for delivery. Additionally, they need to ensure these tasks get in to the electronic tool before the remote team starts their Sprint. During the Sprint, this proxy will keep an eye on progress, move the stickies to match the electronic board, and talk to the remote team at least once a week.
If it is a local team only, and they insist on an electronic tool, I like having the Scrum Master responsible for synchronizing the two systems.
It’s a rather long list on Amazon.
http://icanhaz.com/AgileForSoftwareDevelopmentOrganizations
Sorted by fundamentals, then technical, some management and enterprise in there, too.
What would you like to see added to it?
Constant Change by Aaron Sanders is licensed under a