It’s official: Agile methods are gaining momentum in the Federal Government. I recently sat down to with John Gilroy to discuss the trend at Federal News Radio’s studio in Washington DC.
We had a lot of fun talking through a range of topics, whether it be the key concerns federal project managers have with Agile methods, which agencies are using them, and the procurement experiments to enable them.
This episode of “Morning Fewell”: Surprise Special Guest Santa Claus! Santa invented agile methods?
Share a few minutes with me during your morning coffee time – it’s sure to charge you right up!
In this episode of “Morning Fewell”, we discuss the new update to PMI’s Agile Certified Professional (PMI-ACP) certification. Below the video I have a summary of my key tips for getting started with the certification.
Share a few minutes with me during your morning coffee time – it’s sure to charge you right up!1) To learn about what’s involved with the certification, go to http://www.pmi.org/agile to find the following:
– Check out the “PMI-ACP Handbook” listing the certification requirements
– The “Exam Content Outline” which lists the learning objectives, topics, and techniques covered by the exam.
2) The best 2 books to prep for the exam are the following:
– The big book targeted by Mike Griffiths for those who need more exposure to agile methods as they head to the exam: https://www.amazon.com/PMI-ACP-Exam-P…
– The compressed book by Andy Crowe for those already confident in agile methods, and only want to focus on the exam: https://www.amazon.com/PMI-ACP-Exam-P…
3) For workshops or bootcamps to prep for the exam, look for classes taught be the two authors above
This is so cool, I can’t believe it.
Many of you know that I have a quarterly column in the Project Management Institute’s premier member magazine, PM Network, called “The Agile Project Manager” The latest-and-greatest issues are reserved for paying members in good standing, but you can see some of those older columns here.
Well, I am delighted to share with you all that the team over at PMI’s Japan chapter has liked them enough to begin translating some of those pieces into Japanese.
The most recent translation is available only for chapter members. However, if you’re curious what an Agile PM column looks like in Japanese, you can download an older piece below.
Hi there – This blog is focused on some videos I’m excited about.
First, we are introducing “Morning Fewell” on our Youtube Channel! Share a few minutes with me during your morning coffee time – it’s sure to charge you right up! This episode: What? No Estimates!?!
Second is an interview on the topic of Virtual Collaboration from the Agile2015 conference last month conducted by the Every Voice Engaged Foundation.
Psst! Hey You! It’s coming!
Virtually Agile. The most powerful resource that you’ve ever had access to… is coming. Right now, a select group is testing for us, and then hold on for the ride, because you will see the first of its kind!
“Virtually Agile”. Stay Tune.
Scrum is by far and away the most popular of all the agile methods in use today. A key feature of Scrum is the distribution of responsibilities across three roles: a business representative (Product Owner), a group of skilled professionals building a product (Development Team), and a facilitator who removes obstacles (ScrumMaster). These roles have become ubiquitous in Agile projects across the world.
Several people have tried to answer this question with a good old fashioned RACI chart (responsible, accountable, consulted, informed). Whether a this downloadable PDF, or detailed treatise, or even an article published by the Scrum Alliance itself. Unfortunately, each of these “Scrum RACI” examples to try to do too much, offering up way too much detail that leaves many of my clients wondering about how it works on their project instead. I think the RACI format itself is to fault. What if we answered a more basic question instead? More to the point,
“What does the textbook say about who-owns-what, regardless of what kind of project I work on?
Instead, I’m going to use a different approach, by emphasizing who owns a given responsibility versus who helps that owner. I find “Owns-Helps” is much easier to articulate than the conventional RACI format. First, I’ll share the infographic you can download, followed by a description.
The Product Backlog, and its related Refinement, are absolutely owned by the Product Owner. She decides which workshops, meetings, plannings, or updates need to happen to create and update the backlog. However, a good Product Owner will ask for help from the Development on dependencies, estimates, tradeoffs, and event test criteria. She will also ask the ScrumMaster to help resolve any issues. A ScrumMaster can help facilitate alignment across stakeholders. The Product Owner can even ask for help organizing the backlog in a way that is understandable by various parties.
The Sprint Planning and its resulting Sprint Backlog are jointly owned by the Product Owner and the Development Team. The Product Owner decides what is most important to work on right now, in the upcoming Sprint. Meanwhile, the Development Team decides how much of the Product Owner’s priorities are feasible in the Sprint’s timeframe. If they’re good their job, they’ll ask the ScrumMaster to facilitate some good dialog about this difference of perspective. Granted, the Development Team can spend some time in the meeting to craft a tactical plan for how the backlog items will get built. That may help them gain confidence as to what’s feasible for the Sprint. But whatever goal, whatever agreement, whatever forecast comes out of Sprint Planning is jointly owned by the Product Owner and the Development Team.
The Daily Scrum and the Product Increment are absolutely owned by the Development Team. Nobody touches the Product Increment during the Sprint, except the Development Team. Also, they use the Daily Scrum meeting as a tool to help them coordinate the steps and actions needed to build the Product Increment. If they are wise, they will ask the Product Owner for help to clarify business details, or even to shield them from other stakeholders. Furthermore, they can ask the ScrumMaster for help facilitating the Daily Scrum and removing impediments. The newer the team, at the more help they will need. A common rule is that “anyone can come to the Daily Scrum, but only the Scrum Team is allowed to talk at the meeting”. This is to emphasize that the ceremony is owned by the Development Team, for their own internal benefit.
The Sprint Review is owned by the Product Owner. This is where the Product Owner gets to see what she invested the last few weeks of budget to get. She decides whether the product is in good enough shape to invite stakeholders. She decides how best to capture feedback during the meeting, and have it incorporated into the backlog. If she’s smart, she’ll ask the Development Team for help to demo the product and , since they just worked on it. She can also ask the ScrumMaster for help in establishing an effective meeting.
The Sprint Retrospective is jointly owned by all three roles. The Product Owner’s neck is on the line for how well the Sprint went; she will have strong opinions about improving. The Development Team is expected to take ownership over their work; they will have ideas about how to make that happen. The ScrumMaster is held accountable for whether the whole team is effective and reliable; he will have strong opinions about moving in that direction.
This “Owns-Helps” chart shows us that Scrum itself is a very simple framework. Granted, the devils is in the details. But Scrum leaves you to answer the question of HOW those details are attacked in your specific context. There is an the ebb and flow of responsibilities across the three roles of a Scrum Team. This yin and yang fluctuates during the course of the Sprint. It fosters more collective ownership, and allows for each of the roles to have greater focus on their specific areas.
I’ve had it.
The other week I heard the umpteenth person make some misguided, mistaken declaration about the rules of Scrum. I hear it way too often. “Scrum says this” or “Scrum says that”. There is a ton of misunderstanding out there about what Scrum is and what it isn’t, and it’s driving me crazy. Using the Scrum.org Scrum Guide and the ScrumAlliance’s definition of Core Scrum in the Agile Atlas as our official definitions of Scrum, let’s see if you’ve heard any of these biggest offenders:
5) “Scrum says we have to estimate with story points”. Um, no it doesn’t. The Guide and the Atlas give very specific guidelines for when to estimate Product Backlog Items. So, you may be surprised to learn Story Points are decidedly NOT included in those rules. In fact, Scrum co-founder Ken Schwaber has been an ardent promoter of Ideal Days. Which estimation technique you use DOES NOT MATTER, only that you use the technique consistently.
4) “Scrum says the product backlog may only include User Stories”. Oh, and while we’re at it, user stories are NOT mandatory. YES, user stories are a great technique, and YES they facilitate a more robust understanding of the work that needs to be done. But the Scrum Guide does not mention them at all, and the Agile Atlas lists them only as a Generally Accepted Scrum Practice (GASP) and not a part of Core Scrum . If you have a thousand requirements formatted as “the system shall provide…”, and they consistently meet the INVEST principle, then please don’t go spending 2 months rewriting them into the “as a, I want, so that” format. Also, don’t forget infrastructure work and spikes should be well groomed Product Backlog Items, but force-fitting them into User Stories can often be clumsy. The goal of any Sprint is to produce a product increment of running, tested features; however you do that is up to you.
3) “Scrum says the Product Owner is not allowed to attend our meetings.” Okay, I see why you might misinterpret this from the Scrum Guide’s rule that “only Development Team members participate in the Daily Scrum.” However, the Atlas asserts a clarifying counterpoint that “only the Scrum Team members, including ScrumMaster and Product Owner, speak during this meeting.” Specifically, it is totally possible (and even desirable) for a ScrumMaster to facilitate a positive dynamic for the meeting, without actively participating in the conversation. Likewise, as a full and equal member of the whole Scrum Team, the Product Owner has every vested interest to observe the meeting, and offer some assistance to the Dev Team Members. The key here is that we protect the self-organizing dynamic of both the internal Development Team and the broader Scrum Team.
2) “Scrum says the Product Owner must be the product business sponsor”. No, Scrum doesn’t say that. Scrum is a team-level method. The Atlas says “The Product Owner is typically the individual [on the Scrum team] closest to the ‘business side’ of the project.” Each and every Scrum team has a team-level business point of contact “who is expected to do the best possible job of satisfying all the stakeholders.” That includes the product business sponsor, the executives, and even the Product Owners of the product’s other Scrum Teams. Often, the business sponsor doesn’t have enough people to staff a team-facing Product Owner for each and every Scrum team. So, we will recruit a Development Team (a business analyst or a tester, maybe) to step up and play the part of the team-level Product Owner. Then, that person will be the one “responsible for maximizing the value the product and the work of [that specific] Development Team.”
…and coming up at Number 1…
1) “Scrum means we don’t do any up front planning”. Really? Where does is say that? If you believe that, then let me ask you this: where does the Product Backlog come from? Can you start Sprint 1 without one? You have to do some minimal amount of Product planning BEFORE you begin formal Sprint Planning. In fact, both standards require Grooming or Refinement as a means “to prepare for the upcoming Sprints” [fromt the Atlas]. Then, after the first Sprint begins, the Guide explains that Grooming continues “as a part-time activity during a Sprint between the Product Owner and the Development Team…[consuming] no more than 10% of the capacity of the Development Team.” Furthermore, the larger the product initiative, the more Grooming and Refinement will be needed in advance. Just don’t go planning all the details of all the features for the whole product.
What about you? Have you heard these in your workplace? What other have you heard that are annoying?