- retiring Oracle data warehouse licenses / servers,
- retiring disk space / hardware,
- and saving CPU time with new hardware
The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision. In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.
Scrum has really come far!!! Check out “Scrum Your Wedding“. I love the ScrumMaster and Product Owner tips. Here’s a good one:
SCRUM MASTER TIP – The stand-up is overkill in most wedding planning scenarios, but we do think it’s useful to ask the questions at least a few times per sprint, perhaps over email. It’s your job to make sure the questions are asked and answered.
They have taken the core ideas of Scrum and made some intelligent modifications to make it suitable for a fixed deadline event planning scenario. Honestly, I think that the ideas presented here could be a great approach to doing Scrum on other similar fixed deadline projects. Thanks to Hannah Kane and Julia Smith for creating a unique and useful resource!
The Scrum Alliance just announced through a press release the Added Qualifications [PDF] program. From the release:
The Added Qualifications program will begin by first offering courses in Scaling Scrum Fundamentals. Those interested in earning an Added Qualification in Scaling Scrum Fundamentals will need to hold at least one of two foundational certifications, Certified ScrumMaster® or Certified Scrum Product Owner®.
More information can be found on the Scrum Alliance Added Qualifications page.
Through World Mindware, we will be introducing courses over the next months to help you achieve these new Added Qualifications.
I was poling around for a good definition of DevOps and found a thoughtful article written by Ernest Mueller called What is DevOps? Highly recommended reading as it includes lots of insight about the relationship between Agile and DevOps. FWIW, I feel that the concept of the Definition of “Done” is Scrum’s own original take on the same class of ideas: breaking down silos in an organization to get stuff into the marketplace faster and faster. I even talked about operationalizing software development back in 2004 and 2005 as a counterpoint to the project management approach which puts everyone in silos and pushes work through phase gates.
Thanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations. It is available for purchase (only $2.99) on lulu.com (that’s where the link goes). Here is the blurb about the book:
Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular AgileAdvice.com blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including “Agile Mining at a Large Canadian Oil Sands Company”, “Crossing the Knowing-Doing Gap”, and “Becoming a Professional Software Developer”. Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.
Once you have read it, I would love to hear your feedback and reviews here. I will try to publish updates quarterly over the next year to make it even better! Thanks again for your support.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
Ten Most Commented Upon Agile Advice Articles
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
Plans for the Future – Five Top Ideas for Series
Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
|ScrumMaster||Product Owner||Project Manager||Team Lead|
|NO||Define Business Requirements||PARTICIPATES||NO|
|NO||YES (Deliveries)||Define Milestones||NO|
|YES (process and people)||YES (business)||Risk Management||PARTICIPATES|
|Organizational Change Agent||NO||NO||NO|
|NO||Accountable for Business Results||RARELY (just costs)||NO|
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
TEAM CREATION EVENT AGENDA
Have you experienced an event like this? Did it work? What was different from what I described?
The ultimate purpose of Product Backlog refinement is to ensure an ongoing conversation that increases transparency of the Product Backlog and therefore the Product itself – to orient everyone on the team to breaking out of their waterfall silos and focus on delivering business value, period.
On mature teams, a lot of the refinement work happens as ad hoc conversations while they are sitting around and thinking together about how to build something great because they are just motivated by that and it becomes part of their mode of operation.
The objective of the refinement work of any given Sprint (that often needs to be repeated over and over like a mantra with new, immature teams) is to ensure that the items at the top of the Backlog are transparent enough that the Development Team considers them ready to pull and get “Done” in the next Sprint. This is where the concept of the Definition of “Ready” (DoR) comes from – the Scrum Team defines the DoR and spends up to 10% of its capacity refining enough items at the top of the Backlog so that it can provide estimates (if required) and have a reasonable degree of confidence that it can deliver the items in the next Sprint.
Refinement is NOT solutioning – I think this is the big trap that a lot of teams fall into because there is a false assumption that technical solutions need to be hashed out before estimates can be made (part of the carried-over lack of trust and communication between the business and IT) – I would almost rather throw out estimates in cases where this is not improving – The Planning Game exercise, when facilitated well, lends itself more to increasing transparency rather than solutioning.
The fact that teams are telling us that they need to solution before they can estimate is also an indication of weak Agile Engineering practices such as refactoring, test-driven development and continuous integration (XP). The best refinement sessions are those in which the team is able to focus on the “what” – the business benefit results that the Product Owner really wants – rather than the “how” (solution). Strong teams emerge in an environment in which they are trusted by the business and management to find the right solution as a team. They don’t need to have it all figured out before giving an estimate because they are not afraid to give a bad estimate and fail. Also, if the team is struggling to give estimates, this is often a sign that the Product Backlog Items are too big. Most likely the team also needs to expand the Definition of “Done” to include testing against acceptance criteria within the Sprint so that they can estimate based on that criteria.
The “how” (solution) should be mapped out by the Development Team at a high level in the 2nd part of Sprint Planning (partly why the time box is bigger than they often think they need) and more detailed architecture, requirements and design work as part of the Sprint Backlog
But this level of maturity is very hard to do and it will take a while to get there, perhaps even years.
It also depends on your interpretation of “detail”, the word used in the Scrum Guide to describe what the team does in Product Backlog refinement. To me, it means understanding in more detail what the Product Owner really wants and needs. What does it mean to you?
I just finished reading a great rant about being on time by Greg Savage. It got me thinking a bit. I’ve been involved with Scrum and other Agile methods since the mid-90’s and in that time, my perspective on time has changed considerably.
I used to be the guy who was always late. And it was a completely selfish behaviour. Meetings, outings, even weddings. I just couldn’t believe how “uptight” people were about time. But gradually, over a period of about 5 years as I became more and more aware of the underlying philosophy of Agile, my perspective, and more importantly my behaviour, changed: I started being on time. For everything. Even if it meant doubling my travel time buffer. Even if it meant sleeping 3 hours instead of 8 hours. Even if it meant missing a meal or a drink or a personal to-do item.
Time is the only resource that, once spent, we can never get back.
Scrum and most other Agile methods respect this implicitly in their time-boxed iterations and meetings. But people on Agile teams often need time to adapt and change their behaviour. In many ways, timeliness (starting and finishing meetings on time) is a critical component of the Scrum value of Respect.
Timeliness is also related to our understanding of planning. The Horizon of Predictability is short in most work environments. Maybe a week or two. If you dis-respect the tkmeboxes of the Agile process, you are jeopardizing your ability to effectively use the horizon of predictability. Even the Daily Scrum, normally time boxed to 15 minutes each day, can through abuse of time, cause long-term ramifications in product development planning.
But really, I like Greg Savage’s point better than all the practical stuff: being late is rude. Period.
The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?). One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word. I have posted a response. I strongly believe that the word “commitment” is the right word. Here’s the first paragraph of my response:
Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.
A long time ago I had a really good friend….
Check out all the discussion on the five values of Scrum and please comment or vote (or both!)
The Product Backlog is often described as the primary input to Scrum. The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog. In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog. And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role. I believe in just starting if you can. I even wrote a blog post about this a while back and I stand by it.
I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing. Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start. And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.
The Scrum Guide recognizes the following inputs to Sprint Planning:
A newly-formed team often needs to address the following before the first Sprint:
If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).
Keep it simple. It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product. Get the Product Owner to blow these things out into a list. It doesn’t need to be a complete list. Just the most important things right now. A good test is to give the Product Owner 5 minutes. Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on. There are all kinds of techniques that can be used to order the Product Backlog. The simplest way is to just have the Product Owner eyeball it. If people are uncomfortable with this, then introduce the other ways. It doesn’t need to be perfect. It will get better and become refined and adapted as you go.
Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%). If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post. According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).
This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done. The team needs to know this before it can estimate the items in the Product Backlog as a team. Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.
In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”. Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done. All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built. The team should try to create a set of tasks each of which are a one-person day effort or less. Count the number of tasks. If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog. If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.
Hi Everyone. A Scrum Alliance colleague of mine mentioned that in a conversation with Jeff Sutherland (one of the authors of Scrum), Jeff suggested that the community could request and vote on a change to the Scrum Guide (the official description of Scrum) in order the add the values back to the guide. The values are normally listed as focus, commitment, courage, openness and respect. Please go and vote (and / or discuss) this on the Scrum Guides User Voice page. Voting is super easy – you just need to sign in with Facebook.