Josh asked me to write about some of the challenges and obstacles that we face in our environment. In order to do that I should explain a little about that environment.
Over the past 36 months we have transformed ourselves from being a software development team in crisis to a strong team that is focused on delivering on it’s commitments. In 2005 we determined that the current approach to writing software wasn’t working. We were the poster child for “garage-band” style of software development, having inherited 1 million+ lines of classic (poorly written) ASP code [aka 1MLOC - I'll let you guess what the "C" stands for], and having very little recognition from corporate management that anything was wrong with the way things had been done.
When I came to lead the group in early 2007, I had put in countless hours trying to lead the business toward implementing a PMO. While we actively maintain the 1MLOC, we have been working closely with a third party partner to replace the application. In parallel, we have a number of other small LOB applications that we have written using accepted best practices and design patterns. Needless to say, this means that there is a significant amount of churn and chaos when it comes to determining what’s going to be worked on and by whom. Enter SCRUM.
In early 2008 I approached the IT leadership and explained that an iterative and incremental approach to developing software was far superior, in our environment, to the code-and-fix triage approach to project management that had been promoted in the past and that this would be well suited to supporting the behemoth 1MLOC application while still allowing us to be agile enough to respond to the business’ needs in a timely manner. They bit.
So, what is our environment like, how do we handle some of the obvious gotchas, and what are the advantages/disadvantages to how we do business? Well first, I’ll say that this is what works for us, in our environment. I can’t speak to your situation, although if I can help, please drop me a line. Well, we currently have over a dozen product backlogs that are somewhere in the development/grooming workflow. We have roughly half that many Product Owners [none have been "officially trained", all have gone or are pending admission to the school of hard knocks] and the expectations of what it means to be a Product Owner are communicated loudly and often.
Some gravitate toward the role, others are a little thicker and require some additional coercion encouragement.
Regardless, we do the classic planning poker estimating that I described here and then, based upon our standing team velocity we let the Product Owner how much of the backlog we will be able to knock out during the next sprint. At that point, for any one of a couple reasons [the Product Owner needs more functionality than can be delivered in a single sprint/the team has some groundwork to lay in one sprint in order to deliver the key business deliverable in a second or third sprint/etc.], the team may decide that they need to deliver the next increment of work over several concurrent sprints.
In this case, the backlog of backlogs is queried and the next product owner is queried for budget and schedule requirements [we may even look at the current state of that PO's product backlog] and a reasonable determination is made [by my boss and the IT Steering Committee] whether it’s acceptable to the business for the subsequent development to:
- be delayed
- be preempted or
- be split [deliver Sprint 1-Product A, then Sprint 1-Product B, then Sprint 2-Product B]
From the team’s point of view, this decision is somewhat irrelevant as long as the sprint backlog is ready to be loaded into the SCRUM Dashboard [which is integrated into the Microsoft Team Foundation Server - our source control and overall ALM solution]. Once the tasks are entered into the Scrum Dashboard (which is a lot like SCRUMY except that it’s tied to coding tasks, time tracking, check-ins, build events, etc.) the team tracks their own progress daily which automatically updates the Sprint Burndown, Product Burndown, BurnUp, and a hundred other reports that are hosted in the Microsoft SQL Server Reporting Services site that comes out of the box.
The daily stand-up meetings are usually run by the team, as the ScrumMaster I sit in on them regularly; however, my prime directive is really just to make sure that they’re happening and that there are no discovered impediments that are/have not been communicated to me that come up as an outcome of the meetings. We have a weekly code review meeting for the whole team to see where we are, and we usually use this meeting to demonstrate the application state to the product owner. As part of our development team, we expect for the business to provide testing and QA resources so that we can be sure that the feedback loops are as short as possible.
So, you ask, what are the gotchas in this environment? That’s an easy list to start, but a very difficult one to call complete…so here’s my “easy list”…the hard ones will quickly become evident in your environment.
- Training Product Owners – especially in a “Command and Control” environment, it’s difficult to convey the concept and importance of servant leadership. Similarly, it’s hard to get “busy” business folks to commit their time to things that are commonly deemed to be unproductive
- Training Product Owners- getting them to understand the concepts of story points, estimating, life without requirements documentation and use cases, life without earned value, and ultimately the fact that the ROI and the “fit for purpose” functionality is their #1 responsibility
- Death by meeting – herding all of those backlogs, training all of those Product Owners, daily stand-ups, retrospectives, code reviews, “demo days”, Planning Meetings, not to mention the other “normal” meetings that one usually gets pulled into [weekly staff meetings, employee meetings, annual reviews, etc, etc, etc]…leads to about 80% of your time being tied up in one meeting or another…it really is hard to do a lot more than manage your schedule and check your business card to make sure it matches your driver’s license
- Leadership & Management – if your management doesn’t back you up and get out of your way, you will be tripping over one another. They MUST support you and then get out of your way. The proof is in the pudding…deliver a few times and they’ll get it.
- Tools & Co-location – We are one team, in one location. We tried the distributed team thing for a while and, to be honest, the requirements for the team to be available to meet to review something on very short notice makes co-location extremely difficult. Likewise, much like there isn’t really a “SCRUMBOK” because SCRUM is prescriptive as far as Engineering Practices, there are hundreds [if not thousands] of electronic tools for the team to use…a definite gotcha is the temptation to jump into the midst of the tools arena before you really understand the process that needs to be supported by a tool. We found TFS and SCRUM Dashboard….it’s what works for us….that means squat to you….make your process work analog, and then digitize it….I can’t say this any more clearly…learn to love the whiteboard, post-it, and index cards…worry about the business now and worry about the rest later [it might actually take care of itself].
OK. So there’s a start. That list could go on for a while. So, to wrap up, you’re probably interested in understanding what are some of the pros and cons?
- PRO: We deliver working software, and we do it pretty frequently. This means that our Product Owners are pretty happy. Happy PO = Happy Business = Job Stability = Happy Employees = Better Software
- PRO: We get to deliver at a sustainable pace and we LOVE what we do. I hope that the death marches of 2006 are gone for good. We value people over process. Happy Employees = Better Software = More Projects = Job Stability = Happy Employees
- PRO: We get to be honest and transparent. With the PO on the team, there are no secrets about something taking longer than planned, or something not working as expected. The PO and the team get to figure out how to work thorough these challenges rather than worrying about doing damage control.
- CON: Estimating is really difficult, especially at first. Then, to make matters worse, budgeting is even more vague. For some organizations, this may be too much to overcome. I hate budgeting season…to ask me how much something is going to cost is to ask me for a complete and estimated product backlog, which isn’t terribly different than a preliminary project plan and schedule. Ugh. Budgeting Sucks.
- CON: If you are a “Command and Control”, “Do first, ask questions later”, “take the bull by the horns” kind of manager, you will really struggle with Agile. The CORE of Agile is in empowering the team, transferring that control to them, and settling into a support role….for a lot of folks, this will be impossible.
Related posts:
{ 18 comments… read them below or add one }
Thanks Jim, great stuff!
On the death by meetings point, I’m assuming you mean your time, not your team? Is the time of your team members liberated so they can get more done?
Thanks Jim, great stuff!
On the death by meetings point, I’m assuming you mean your time, not your team? Is the time of your team members liberated so they can get more done?
Thanks Josh. You’re right…the “Death by Meeting” comment is referring to my time. This keeps the team available for things that deliver business value.
Thanks Josh. You’re right…the “Death by Meeting” comment is referring to my time. This keeps the team available for things that deliver business value.
Hi Jim, great post.
I’m “working” on moving to scrum, but one paint point for me and even more for my CEO is one of the cons you have written about: “Estimating”.
Since I see Agile (scrum) as something that may change through the sprints initial specs that were in the scope of the budget: how can I convince the client that other strategic tasks will be done instead of those that were initially planned? How do you address the “budgeting season”?
Hi Albert! Estimating, at the product level, is the most difficult aspect of my job. Scrum is simply a framework for gracefully adapting to change. The philosophy is that, rather than presume that you can completely define the scope of work, you focus on delivering the sub-set of work that you can completely define and let the larger project-level scope of work evolve as the business needs evolve. The benefit is that you’re very likely to deliver what the customer really wants, the drawback is that businesses really want to know how much something is going to cost at the end. We are fortunate to have a relatively fixed-cost development resource (in other words, they’re full-time employees that have burdened costs regardless of whether they’re writing software or not), so the “cost” of a project can be derived from a rough estimate of the number of sprints that will be required to complete the cumulative product backlog. this makes budgeting for the “known” less painful than other types of projects. Those projects that require staff aug or capital expenditure are more difficult and usually require some effort to derive a rough, abstracted scope of work in order to determine resource levels, capex requirements, and required iterations (sprints). I hope that helps.
Hi Jim, great post.
I’m “working” on moving to scrum, but one paint point for me and even more for my CEO is one of the cons you have written about: “Estimating”.
Since I see Agile (scrum) as something that may change through the sprints initial specs that were in the scope of the budget: how can I convince the client that other strategic tasks will be done instead of those that were initially planned? How do you address the “budgeting season”?
Hi Albert! Estimating, at the product level, is the most difficult aspect of my job. Scrum is simply a framework for gracefully adapting to change. The philosophy is that, rather than presume that you can completely define the scope of work, you focus on delivering the sub-set of work that you can completely define and let the larger project-level scope of work evolve as the business needs evolve. The benefit is that you’re very likely to deliver what the customer really wants, the drawback is that businesses really want to know how much something is going to cost at the end. We are fortunate to have a relatively fixed-cost development resource (in other words, they’re full-time employees that have burdened costs regardless of whether they’re writing software or not), so the “cost” of a project can be derived from a rough estimate of the number of sprints that will be required to complete the cumulative product backlog. this makes budgeting for the “known” less painful than other types of projects. Those projects that require staff aug or capital expenditure are more difficult and usually require some effort to derive a rough, abstracted scope of work in order to determine resource levels, capex requirements, and required iterations (sprints). I hope that helps.
Jim,
Great description.
Here in aerospace and defense I know of NO successful Control Account Manager or Program Manager that uses Command and Control.
It’s a fundamental principle of project management that “team” is the critical success factor.
Kotter’s definition of Team
“A group of individuals who hold each other mutually accountable for a shared outcome.” The Project Team has various roles, but the Team in Project Team the key to success.
This is restating the obvious, but for some reason, immature leaders fail to recognize this.
Thanks Glen. In our business [capital projects], the PM’s have fiduciary responsibility for the overall project and rely heavily on command and control. Fortunately, down here in the trenches of a support organization, we’re allowed to run the group as required to deliver the best value. For me, that means using Scrum’s iterative and incremental approach and empowering the team to do whatever is required (within reason) to deliver that value. While the organization seems interested in learning how Lean can be applied to their processes, I don’t have any aspirations [in my current role] of slaying that dragon and trying to evangelize Agile/Lean/Scrum to the larger organization. I respect any organization [specifically those outside of IT (even more specifically those outside of AppDev)] that has recognized how these principles can revolutionize their business. Management wonks like Ken Blanchard and Tom Peters have been describing and, in Ken Blanchard’s case, advocating the abandonment of Command and Control leadership in favor of Servant Leadership for many years. The classic “Art of War” mentality to business that has been taught in business schools for generations seem to struggle with the philosophical contrast between these two schools of thought and how they can have their cake and eat it too…having the benefits of empowered teams while maintaining the benefits of having a heirarchical reporting structure. How has your organization/industry adapted to this paradox?
Jim,
Great description.
Here in aerospace and defense I know of NO successful Control Account Manager or Program Manager that uses Command and Control.
It’s a fundamental principle of project management that “team” is the critical success factor.
Kotter’s definition of Team
“A group of individuals who hold each other mutually accountable for a shared outcome.” The Project Team has various roles, but the Team in Project Team the key to success.
This is restating the obvious, but for some reason, immature leaders fail to recognize this.
Thanks Glen. In our business [capital projects], the PM’s have fiduciary responsibility for the overall project and rely heavily on command and control. Fortunately, down here in the trenches of a support organization, we’re allowed to run the group as required to deliver the best value. For me, that means using Scrum’s iterative and incremental approach and empowering the team to do whatever is required (within reason) to deliver that value. While the organization seems interested in learning how Lean can be applied to their processes, I don’t have any aspirations [in my current role] of slaying that dragon and trying to evangelize Agile/Lean/Scrum to the larger organization. I respect any organization [specifically those outside of IT (even more specifically those outside of AppDev)] that has recognized how these principles can revolutionize their business. Management wonks like Ken Blanchard and Tom Peters have been describing and, in Ken Blanchard’s case, advocating the abandonment of Command and Control leadership in favor of Servant Leadership for many years. The classic “Art of War” mentality to business that has been taught in business schools for generations seem to struggle with the philosophical contrast between these two schools of thought and how they can have their cake and eat it too…having the benefits of empowered teams while maintaining the benefits of having a heirarchical reporting structure. How has your organization/industry adapted to this paradox?
Wow. I’ve been reading your blog off and on for months, and didn’t realize you were a dyed-in-the-wool Scrum practitioner.
I totally agree about the Product Owner / Product Manager having a big hurdle to overcome. Having recently been to PO training, I realized exactly how much I didn’t know about Product Management. Many Agile/Scrum wonks focus so much on the team dynamics, they forget about investing time in that boring scope stuff. We have to equip ALL the team members…including the PO.
Good stuff.
Thanks Jesse, but this post is from Jim Kinter, not I! Just wanted to set that straight.
Thanks Jesse. Training PO’s to :
1) abandon their Command and Control mindset
2) understand that AppDev isn’t us vs. them
3) be empowered and act as CEO of the product
4) accept responsibility for defining functionality
5) track and communicate ROI to the business
This is the most time consuming thing I do. It’s one of my goals for the year to find, or put together some PO training resources that would allow me, in a 1-2 hour class, to train someone completely foreign to Agile/Scrum on how to responsible act as a PO…something more than a document. Are you aware of any lightweight PO training resources like this?
Wow. I’ve been reading your blog off and on for months, and didn’t realize you were a dyed-in-the-wool Scrum practitioner.
I totally agree about the Product Owner / Product Manager having a big hurdle to overcome. Having recently been to PO training, I realized exactly how much I didn’t know about Product Management. Many Agile/Scrum wonks focus so much on the team dynamics, they forget about investing time in that boring scope stuff. We have to equip ALL the team members…including the PO.
Good stuff.
Thanks Jesse, but this post is from Jim Kinter, not I! Just wanted to set that straight.
Thanks Jesse. Training PO’s to :
1) abandon their Command and Control mindset
2) understand that AppDev isn’t us vs. them
3) be empowered and act as CEO of the product
4) accept responsibility for defining functionality
5) track and communicate ROI to the business
This is the most time consuming thing I do. It’s one of my goals for the year to find, or put together some PO training resources that would allow me, in a 1-2 hour class, to train someone completely foreign to Agile/Scrum on how to responsible act as a PO…something more than a document. Are you aware of any lightweight PO training resources like this?