A colleague recently asked whether a team he encountered was agile.
- The team is managed by a smart computer scientist with deep architectural understanding.
- Periodically team meets with the manager and product manager to plan. Together they decide the overall functionality to be delivered by the team, and decide how long they need, typically two to four weeks, which they call “sprints”. They select functionality that they believe they can finish in that time. These are not user stories, but a collection of requirements that seem like they should go together. The work is not directly releasable.
- Since the manager is smart, the team usually defers to the manager’s architectural approach, which consciously considers team member skills. The team decomposes the requirements into tasks, carefully constructed to reduce the need for member interaction. They try to minimize source code clashes in advance, assigning tasks to people carefully.
- The team members typically work in isolation. Although they do not have daily stand ups, they are co-located, so they can always ask co-workers for advice and help. Each is responsible for the tasks he or she was assigned.
Some team members want to use Scrum, but the manager has said, “No. Scrum involves too much process, too many meetings, team members will feel micromanaged.” Continue reading
Many well-meaning people think they can be the First Person Ever to combine waterfall and Scrum, name their new process with some catchy name, start teaching this Frankenstein system, then cause internal organizational chaos or sloth. Continue reading
Estimating lots of work items can help agile teams dramatically: Estimates help Product Owners make trade-offs, help teams gauge capacity, help Product Owner forecast feature releases, and help team members think about architectural issues. However, in too many cases, estimating is painfully boring and slow. It doesn’t have to be.
In my last company, I used to hear people say “We need more people to handle this workload.”
Every group in the company considered in isolation could use more people, no matter what group they are in; at least that’s what most people think. But smart folks sometimes say, “We have too many people.” Continue reading
New cognitive psychology results can help us provide better training. Trainers seek to transform the way you think about tasks, motivation, planning and outcomes, and equip you with enough understanding to succeed. My Scrum Trainings are done in the afternoon, reinforcing learning by exploiting sleep cycles. Further ideas include changing venues from day-to-day, varying ways of applying agile thinking to problems, etc.
As Director of the Agile Program Office at Citrix Online, I trained people in agile thinking, including XP, Scrum, Lean and enterprise-level productivity improvement. I’m keenly interested in approaches that enhance learning, especially in Scrum Training. Agile methods are difficult for many to fully embrace, and I want to do anything I can to help. Continue reading
Concerned citizens might warn you not to stand to close: I rope nearby bystanders into the crime I’m currently committing. So when Scott Downey, the General Patton of Hyperproductive Scrum, told me he was busy crawling wineries near my Santa Barbara office, I suggested getting together. “How about 11:30am for lunch?” I asked. “Perfect,” he said, “See you then.”
Scott arrived, we had a hearty repast, and after agreeing the world needed our genius, I had to get ready to to teach the second afternoon of Scrum Training at Citrix Online. Did he want to come? “Sure,” he said. As we walked into the conference room, I asked if he might like to present some of my slides? “Why not?” he said. When we started looking at them, Scott felt uncomfortable. Could he use his own slides? Continue reading
Agile 2010 was held in Orlando near the Disney Epcot resort August 9 to 13. I focus on agile enterprises and attended many enterprise-focused talks. If you are interested in the developer focused view, Martin Fowler provides his thoughts here. My impressions follow.
Portfolio management is being implemented in conjunction with quarterly “sprints” in other places beside Citrix Online, including Motley Fool (Max Keeler), Tektronix Communications (Brian Miller) and Progressive Medical (Ben Blanquera). The four of us are starting to share ideas and experiences. Continue reading
I presented our work on Enterprise Scrum at Agile 2010 this year. The session was well-attended for a specialized talk like this one (really only suitable for software engineering teams larger than 30 people), with about 40 people in the audience.
Enterprise Scrum: Creating an Agile Company
Enterprise Scrum, a fractal extension of Scrum and XP, has organized all development at Citrix Online since Jan 2009. We estimate team months, run quarterly Sprints, reassign teams, meet in weekly stand-ups. We start or postpone whole projects that use Scrum or Scrum-of-Scrums. No other known companies yet use Enterprise Scrum. It provides extreme visibility and control for CXOs. It promotes agile thinking enterprise-wide, driving adoption outside engineering. It demands NPV justification and forces executives to prioritize decisions transparently. It makes us more profitable. Continue reading
On 9 March 2010, I gave a talk on Enterprise Scrum at the 2010 US Scrum Gathering in Orlando, Florida. I am grateful that about 50 people showed up for my talk, from about 300 total Scrum Gathering attendees. People were intrigued by fractal thinking, by the blunt assertion that engineering teams rapidly burn money, and by the prioritization of work using forecasted Net Present Value. Enterprise Scrum can create very healthy product lines and companies. In a sense, Enterprise Scrum turns enterprises into internal venture capital funders. Continue reading
Most agile teams live in a waterfall ecosystem. When powerful stakeholders—like business partners, customers, other departments or executives—demand future commitments, while interrupting contributors with unprioritized demands, smart Scrum teams raise a protective shield. They make the Product Owner manage stakeholder priorities, and make the ScrumMaster defend them against interference. If anyone provides a date to a stakeholder, it’s going to be the Product Owner: the Single Wringable Neck.
But instead of just defending ourselves against an external onslaught of unprioritized need, we can go on the offense. We can evangelize agility upstream. Impossible requirements point out that stakeholders could themselves benefit from agility. If we teach them agility, they and we will both go faster. Together we can develop a strong, sustainable and profitable business ecosystem.
My buds and I have pushed agile upstream twice recently, and it’s more fun than you might think. Continue reading