Written by Mike Cottmeyer Saturday, 16 January 2010 11:34
Program Management Guidance http://bit.ly/63ALKt
Project Managers. On Video? Awesome! http://bit.ly/8F8zVj
4 Questions To Ask About Aging “To Do” List Tasks http://bit.ly/6zKWlj
6 Simple Questions for Neal Ford http://bit.ly/5m9ep0
From Waterfall to Agile: An Exclusive Interview with VersionOne’s Ian Cu.. http://bit.ly/8vGo5X
The dirty secret of pair programming http://bit.ly/4yDDVz
Kanban for Continuous Improvement http://bit.ly/6EVCa8
Visions of Software Development or Can’t We Just All Get Along? http://bit.ly/5a8bfD
Technology is not the Solution – Again http://bit.ly/6T6zk5
Self-discipline and Self-organization http://bit.ly/8509u1
My Merge of GTD and Kanban http://bit.ly/5kZrjv
How Kanban Got Hot – David Anderson Interview Part I http://bit.ly/90kJmg
Spouses, death-marches and Scrum http://bit.ly/87Rpqd
Be your users’ best friend http://bit.ly/6ArqNq
More on Lean, Backlog and Little’s Law http://bit.ly/4P1sMJ
My Overview of Agile Presentation (to a local PMI Chapter) http://bit.ly/8iWVBlJoin the conversation. There is currently 1 comment.
Written by Mike Cottmeyer Saturday, 16 January 2010 07:06
We are almost to the end of the first chapter. This section of the book gives an overview of some of the major concepts around this idea of a value driven agile transformation. It a nutshell, we are talking about finding your critical path… your primary constraints… and start getting better at doing that first. There is some work around figuring out what that constraint is, but we are going to help with that too. After this, I am going to start explaining how we plan to layout the book’s structure.
Value Driven Agile Transformation is about understanding what your organization values and how it delivers value to its customers. Once we understand clearly what is valuable to our business, we’ll assess the organizational structures and processes you’ll need to create that value. We don’t need to get better delivering everything, just those areas of your business that are going to help move value out the door faster. The idea is that we’ll build agile teams around those parts of your business most likely to create valuable outcomes. This is where you will invest in process improvement and change.
As you progressively assess your organization looking for improvement opportunities, you always focus on the next most important area to improve; and you’ll build more agile teams around those capabilities. You’ll replicate what you have learned adopting agile with your first team and replicate that success across many teams. Once you are good at developing working agile teams, it is time to get more than one team working together to deliver more complex project deliverables. This involves a more robust look at agile project management that just isn’t possible until teams can reliably deliver.
Next we have to look at coordinating multiple initiatives through the organization so we can reliably and predictably deliver more than one project at a time. Trying to get many projects running simultaneously is the area of agile portfolio management. To this point, we will have extended much of what we know about agile to work in larger enterprises, but to address agile portfolio management, we will heavily leverage Lean and Kanban concepts as well as Goldratt’s theory of constraints.
When we talk about enterprise agile transformations, we are suggesting an enterprise that systematically focuses on its next improvement opportunity. One that builds agile teams around those delivery capabilities, and incrementally adopts program and portfolio management and ultimately learns how to manage the flow of value across all components of the larger delivery organization. At true enterprise scale, this including upstream capabilities like marketing and sales as well as downstream capabilities like deployment and support.
This approach requires top down leadership and a bottom up implementation. One where leadership sets the direction and establishes constraints, but with teams that are empowered to operate within those constraints. It requires us to understand how our company creates value, the mechanisms by which that value is created, and how we can most improve to deliver that value. It is a solution that is respectful of the overall organizational systems in which value is delivered. This approach recognizes that financial resources are not unlimited and that we have to invest in ways most likely to yield business outcomes.
We want to recommend an approach that respects the individual and makes work a fun place to be. We want to help you create an environment where people are respected and empowered and challenged to deliver more than they thought they ever might. We also want an environment that is laser focused on business outcomes and creating shareholder value. Unless we are selling products, businesses will not be in business for very long. This is not agile for agile’s sake.
Join the conversation.
Written by Mike Cottmeyer Friday, 15 January 2010 01:45
This year SQE is doing a combined conference in Vegas. There is the normal Better Software Conference and Expo, but this year they are doubling up and offering an Agile Development Practices West. I was fortunate to do my Agile PMP talk last year at both Better Software in Vegas and again at Agile Dev Practices in Orlando. The fact that SQE is offering both of these events in a single event, and for one low price, is absolutely amazing.
This year I decided to take a different approach with my conference submissions. Rather than talk about the whole Agile PMP thing, I want to talk more about the ideas Dennis and I are writing about in the book and what I am doing working for Pillar. It is so important that people know and understand the big picture when the decide to start down this path of agile transformation. This isn’t just a project level set of issues… agile transformations ultimately impact nearly every part of the business. We need to talk more about this…
Agile methodologies are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are exploring the possibility of implementing these methodologies across the entire product delivery organization. These managers launch their adoption efforts only to uncover many common myths, misperceptions, and obstacles that derail their efforts before they really get started. Organizations fail to become agile because they don’t understand what makes agile teams work.
Mike Cottmeyer is the Vice-President and General Manager of Pillar Technology Southeast. Pillar Technology is a leading provider of agile transformation services helping companies develop the technical practices and leadership competencies required for sustainable organizational change.
Join the conversation. There are currently 2 comments.
Written by Mike Cottmeyer Friday, 15 January 2010 01:12
This is primarily a book to help managers like Frank. It is directed at the mid-level manager that needs to develop an approach for adopting agile within their part of a larger organization. These are people that want practical guidance on what to do next and how to articulate why what they decided is the next right move. Managers like Frank need a framework to facilitate conversations about what to focus on first and how to build their organizations within a larger organizational context. They need to understand how their decisions impact their teams and how their teams impact the larger enterprise value streams.>div>
This book is geared toward helping these managers incrementally adopt agile and build out a scalable agile enterprise. That said, agile methodologies are primarily intended to work with small teams and not necessarily designed to scale. When it comes to agile in larger enterprises, we find that much of what is prescribed is incongruent with where most organizations find themselves.
“A light framework that leaves out things that are sometimes useful can be smart. One that leaves out things that are virtually always useful is ineffective”.
Allan Shalloway, NetObjectives
To effectively build a sustainable agile enterprise, we will need to go beyond some of our standard agile thinking and incorporate learning’s from the methodologies that came before (waterfall and RUP) and those that are coming after (Lean and Kanban). We will draw from luminaries in the fields of manufacturing, team dynamics, organizational design, change management, systems thinking, conversation theory, and organizational learning. Along the way, we’ll need Goldratt’s Theory of Constraints, Covey’s Seven Habits, and Kotter’s Leading Change amongst many others.
Join the conversation.
Written by Mike Cottmeyer Thursday, 14 January 2010 09:00
Okay, this is a long post… I didn’t want to break it up because these next few paragraphs represent a complete thought. If you’ve been reading my blog for at least the last 6 months, you have seen some of this before. We are continuing to establish context by working through a couple of personas for the book. We have one for the target manager we are writing for and another for the company that he works with.
When you set out to tackle any problem as big as an enterprise wide agile transformation, establishing context is a critical part of figuring out how to move forward. This kind is not a one-size-fits-all strategy! To begin, we want to describe the person we hope will be reading this book. We want to explore the kinds of companies these people might work for and the types of organizational problems they are dealing with. We hope that by helping you understand context, how we understand and approach the problems you are trying to solve, you’ll be able to take these ideas back to your company to apply them in a situation specific way – a way that is tailored to work best for your particular organization.
We’ll establish context by building a persona for both our ideal reader and the organizations where he or she might work. If you’re not familiar with the idea of a persona, they are a way of specifically representing different user types within a given demographic. They are a common way of helping software engineers understand how a user might interact or respond to a system they are building. Our personas are here to help you understand how a typical manager, or a typical company, might respond to the kinds of challenges they’ll face transforming their organizations. We’ll use these personas to explore the behavior patterns, goals, attitudes, and learning outcomes in a more realistic and concrete manner.
Our personas are derived from dozens of people and dozens of companies we have worked with over the past 20 years. It is often surprising to us the universal nature of our human experience and how people and organizations tend to have the same challenges; no matter what the size of the company, the product it makes, or the market it serves. Our goal was to create a set of personas general enough to capture the breadth of our organizational experience, but specific enough that you might see yourself, and your company, in the examples. If nothing else, these personas will help personalize, and give concrete anchor points, for many of the ideas in this book.
With that we’d like to introduce you to Frank Michaels, an up and coming development manager looking to make a difference in his organization, and StandardCorp, a mid-sized company in the midst of significant growth, and all the change that comes along with it.
Frank is 34 years old, married, and has two young children. He earned a bachelor’s degree in Computer Science from his local state university. He has worked professionally for a little over 10 years and earns just below 120K per year. Frank joined his company four years ago as a senior developer. He is considered by his manager to have excellent technical skills and an open mind. Frank is a hard worker, likes to try new things, and has consistently demonstrated an ability to deliver tough projects.
After only a year on the job, Frank was asked to serve as a team-lead. It wasn’t long afterwards that he his boss took a Director role and Frank was promoted to a manager. With this recent promotion, Frank now has several teams under his control and has to interact more directly with the other managers in his department. He coordinates with these other functional managers to drive work through the organization. Frank works with a team of project managers that coordinate delivery across several functional silos within the larger development organization.
Frank is often frustrated by how long it takes to get projects delivered and how little control he has over business outcomes. He often questions his decision to become a manager. Frank spends way too much time in meetings and just isn’t interested in all the corporate politics and maneuvering. His company takes more than a year to bring new products releases to market and it isn’t getting any faster, if anything they seems to be getting slower. Project schedules are unpredictable and cost overruns are common. To make things worse, quality has been suffering as pressure to deliver has gone up.
Frank’s Company, StandardCorp
StandardCorp is a public company that has been in business for 20 years. They grew organically for the first 10 or 15 years by building software for the insurance industry. Several years ago the senior leadership team launched a strategy to grow through acquisition and branched into the financial services sector. StandardCorp is now about 5000 employees with most of their offices in North America, although they have a few sales offices in South America, Europe, and Southern Asia. The product development organization accounts for a third of their total headcount.
As StandardCorp’s product lines became more diverse, they started looking for ways to leverage common infrastructure components and shared services as a way to reduce their overall cost of ownership. The product teams began looking for ways to combine product offerings to create competitive differentiators in the marketplace. Several initiatives were launched to standardize their diverse technology platforms, but these initiatives have been expensive, and success has been sporadic. In fact, these initiatives have slowed down time to market and made products harder and more complicated to deliver.
Product Managers are frustrated because only a few years ago they had total ownership of their requirements. They had direct access to the technical teams they needed to deliver new features to market. As the organization has grown, there is more negotiation required across a larger and more diverse set of stakeholders. The delivery model has become more complex and it takes forever to get any product out the door. In frustration, the product teams specify larger and larger initiatives because they know it will be at least 18 months before they get another change to bring anything to market.
StandardCorp is successful, but everyone understands something needs to change. They are investing heavily in CMMi, ITIL, and hiring PMP certified project managers. Because costs are going up and revenue is going down; StandardCorp is taking a large part of its development organization offshore. They have to increase profitability and recover market position or the company will likely be acquired. To the senior leadership team, it looks like the offshore approach is working. Management has asked the organization to move more of the core development to India and is looking to layoffs as a way to further reduce overall development costs.
Thinking Past Our Personas
The fact that Frank is a married man with two kids not actually an essential element for our story. Frank could just as easily have been Francine, a single Mom with one daughter, or Franklin an older manager with no children getting ready for retirement. What is essential about Frank is that he has something to lose. Many people are working hard just to pay their bills and trying to get a little bit ahead. Helping to make things better, leading change if you will, is difficult and often puts your career at risk.
“And let it be noted that there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful in its success, than to set up as a leader in the introduction of changes. For he who innovates will have for his enemies all those who are well off under the existing order of things, and only the lukewarm supporters in those who might be better off under the new. This lukewarm temper arises partly from the fear of adversaries who have the laws on their side and partly from the incredulity of mankind, who will never admit the merit of anything new, until they have seen it proved by the event.”
Nicolo Machiavelli, The Prince
Frank’s position in the company puts him square on the first or second rung of the corporate ladder. He has influence over several teams, but not necessarily over his peers. He might be able to influence up the organizational hierarchy, but that influence is based solely on the strength of his relationships. Frank can influence his manager, and maybe his manager’s manager, but probably not much past that. Depending on how large and how deep StandardCorp becomes, significant decisions about process and methodology are happening at much higher places in the overall organization.
StandardCorp is at that stage of corporate development when it becomes time to grow up and start putting real process in place. Many of us have worked in small companies that have lightweight governance and everyone works together toward common unifying goals. These companies don’t need much process and structure to get things done. As these companies get bigger, they start to hit the limits of their ability to self-organize and self-direct. Some decide to go down the path of increased specialization and greater process overhead and control. This doesn’t only happen to companies with 1000’s of developers, it happens in companies with as few as 50.
Your StandardCorp might be that 50-person development shop. It might be a division of a 20,000-person company. You might be a smaller shop that just got acquired and is now expected to follow the parent company’s standard processes and procedures. The size of StandardCorp is not our essential element, nor is it the industry. What is important about StandardCorp is that they are big enough to encourage specialization. It is big enough that establishing better processes sounds like a reasonable and responsible approach to get better outcomes.
StandardCorp is big enough that it has a larger, more diverse product offering and is now looking for ways to better leverage its assets. They have reached a point where there is distance between the people making decisions and the people doing the work. This distance blurs the direct mapping between day-to-day activities and the business outcomes that make the company successful. Management begins to operate at much higher level of abstraction and the impact of decisions on individuals becomes less visible, and therefore less important.
Upcoming Training Classes
2-Day ScrumAlliance CourseCertified ScrumMaster(Sold Out)
December 2-3 Orlando, FL
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep
December 5-6 Alpharetta, GA
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep (Sold Out)
December 9-10 Washington, DC
2-Day ScrumAlliance CourseCertified ScrumMaster
December 12-13 Alpharetta, GA
2-Day ScrumAlliance CourseCertified ScrumMaster
December 16-17 Washington, DC
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep
December 19-20 Westminster, CO
2-Day ScrumAlliance CourseCertified ScrumMaster
February 20-21 Alpharetta, GA