Herding Project Managers

Last week Glen Alleman published a post called "The Role of Project Management". Glen has been exploring some of the concerns people have with the PMI and the PMP certification. He is challenging us to tell him what process groups and knowledge areas we should leave out. What should we NOT be doing that the PMI prescribes? If we think that the PMI has it wrong, what should we be doing differently?

It dawned on me after reading his post that most Agile Practitioners I talk with don't really have much first hand knowledge of the PMI, the PMP, or the PMBOK. They know of these things through the people that they have worked with over the years. Quite a few folks I meet have had pretty bad experiences with PMP certified project managers and therefore think that it must be the PMI or the PMP that is making them bad.

For the sake of helping everyone rise to Glen's challenge, I have attached the PMI Process Groups, the Knowledge Areas, and as an added bonus, the Project Management Processes. My guess is that the Process Groups and Knowledge Areas are going to make the cut. What about the PM processes? Any low hanging fruit? Activity sequencing maybe? What about activity resource estimating? How about managing the team?

This is looking to be a pretty tough assignment.

PMI Process Groups
(these are the high level components of the process)
Initiating
Planning
Executing
Monitoring and Controlling
Closing

PMI Knowledge Areas
(these are the areas we are managing within the process groups)
Integration
Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurement

PMI Project Management Processes
(these are the actual process prescribed in the PMBOK)
Develop project charter
Develop preliminary project scope statement
Develop project management plan
Scope planning
Scope definition
Create WBS
Activity definition
Activity sequencing
Activity resource estimating
Activity duration estimating
Schedule development
Cost estimating
Cost budgeting
Quality planning
Human resource planning
Communications planning
Risk management planning
Risk identification
Qualitative risk analysis
Quantitative risk analysis
Risk response planning
Plan purchases and acquisitions
Plan contracting
Direct and manage project execution
Perform quality assurance
Acquire project team
Develop project team
Information distribution
Request seller responses
Select sellers
Monitor and control project work
Integrated change control
Scope verification
Scope control
Schedule control
Cost control
Perform quality control
Manage project team
Performance reporting
Manage stakeholders
Risk monitoring and control
Contract administration
Close project
Contract closure

Check out this link just for fun: http://www.ibiblio.org/Dave/Dr-Fun/df200210/df20021001.jpg

 Subscribe to this blog

Subscribe to Leading Agile

We're Agile, Now What?

You’re a PM working with a team that has just gone agile. Here are a few tips to help you be successful managing agile projects:

Understand agile team dynamics

Agile is about creating an environment where team members are fully engaged and empowered to make decisions. A good agile team is transparent and apolitical. It is a fun and safe place to work. A big part of your job as an agile project manager is to create this environment for your project team. The more you can understand about what makes agile teams work, the better positioned you will be to help them be successful.

Champion the project vision

Sometimes the team is going to get in the weeds. Your job is to help them stay focused on the big picture. Own the project vision. Keep it front and center during planning meetings. Use the vision to make sure the team stays on course. Keeping everyone focused on the goals of the organization is a huge contribution to your team and the business.

Remove obstacles

Listen to your team. Understand what they are telling you. Become an enabler by helping the team deal with the problems that are slowing them down. Be proactive and help anticipate risks. Deal with issues before they become impediments. Create a network of informed company leaders that can help resolve issues when they get too big for the team to deal with locally.

Focus on team building

Create opportunities for the team to have a shared experience. Create an environment where people can develop strong relationships at work. Help develop a sense of shared purpose and camaraderie. Great teams work together and like each other. Great teams are sensitive to each other’s needs. Don't let this happen by accident, be intentional about it.

Build consensus through facilitation

You have created a high performance team focused on the business vision. Get out of the way an let them deliver. At this point you become a facilitator for the team. Learn techniques that help people come to consensus and resolve conflict in a healthy way. Recognize ways to help ensure everyone on the team is able to contribute. Help the team find common ground and get moving.

Develop talent through coaching

Become a teacher. Help set expectations for the team. Most importantly, put people in position to be successful and give them the tools to deliver. One of the best ways to do this is to develop your coaching skills. Learn positive ways to give feedback. Create non confrontational ways to guide and instruct. Build relationships and be open to feedback in return.

Encourage structure and discipline

Maintaining structure and discipline requires energy. One of your primary responsibilities is to help the team maintain focus and protect the process. Encourage participation in planning meetings, daily stand-ups, and retrospectives. Help your product owners find time to maintain the backlog. Encourage discipline around agile engineering practices. Help the team understand how all the practices work together.

Help the team commit

Agile is about delivering on time… every time. On time delivery requires commitment. It requires the commitment of the team to deliver the sprint and the commitment of the product owners to adjust as we learn more about the evolving solution. As an agile project manager you can help create a sense of shared ownership and a culture of collaboration and cooperation amongst all the team members.

Get help when you need it

Having a good support system is essential . Find people on the same road to share the journey with you. Seek out people that have travelled the road before you. Join user groups and share your ideas. Join organizations and find ways to contribute. You will learn much along the way. Never hesitate to ask for advice.

Be patient and stay the course

You are going to have challenges and you are going to make mistakes. There is a learning curve and some old habits will die hard. Hold yourself accountable and learn from your mistakes. Most importantly, don't give up.

Being an agile project manager is about being a great leader. It is about accepting input from reality and responding to it. It is about looking out for the best interest of the team. Seeking out what is not being said. Helping to bridge gaps in understanding. Exposing what is hidden.

There is no success for anyone unless we are all successful. By working for the success of the team, you are working for your own success. You cannot have one without the other.

Here is a link to my post on Agile Chronicles: http://blog.versionone.net/blog/2008/03/were-agile-now.html

 Subscribe to this blog

Subscribe to Leading Agile

The Agile Power Shift

Agile methods move us away from traditional command and control project structures and toward processes that encourage team empowerment and self-organization. This team centric approach represents a real power shift that can leave the traditional project manager wondering about their new role on an agile project.

Some have gone so far as to question if a project manager even has a role on an agile team.

In my last few posts I have been discussing the idea of simplicity and simple rules frameworks. I am trying to drive home the point that agile methods are not designed to tell the whole story. They are minimally prescriptive. They give us a handful of techniques and a whole lot of principles and values. These techniques, principles, and values serve as guides to shape our more complex decision making.

Our decisions must be guided by experience, and for many of us, our experience comes from many years managing more traditional projects. It comes from what we've learned on the job and studied in the PMBOK. A traditional project manager has the potential to contribute a wealth of knowledge, experience, and discipline to an agile project; there are a just few things we need to think about a little differently.

Being agile means you accept input from reality and respond to it. That is really the main difference. Let's embrace PMI concepts like rolling wave planning and progressive elaboration and really learn how to apply them. Let's figure out how to leverage what we know about traditional project management, get really good at accepting input from reality, and help develop project teams that are able to respond to changing circumstances.

Real power comes from helping the team be successful. Real power comes from delivering value to our customers. That is what Agile Project Management is all about.

 Subscribe to this blog

Subscribe to Leading Agile

Restrooms, Canoes, and Agile Metaphors

I came back to my desk yesterday and it was gone. Yep... just empty floorspace where my desk used to be. As you might imagine, VersionOne has a pretty mobile floorplan. Wireless internet and lots of power everywhere. The environment is pretty conducive to moving furniture around so people that need to work together can easily relocate.

After finding my desk missing, I went looking for it. I walked around upstairs, no desk. I walked around downstairs, no desk. I looked outside and then started exploring conference rooms... no desk. Hmmmmmmm. Where might my desk have gone? Well, it seems the dev team decided to play a little trick on me. They moved my desk into the ladies restroom. Nice.

To add insult to injury, they took pictures and posted them to the company blog. Check out http://www.agilechronicles.com/ for pictures and commentary. I have to admit that it was pretty funny having full power and internet access, all my books and even my lamp all crammed into a bathroom. Imagine the productivity gains not having to step away when nature calls. The possibilities could be endless.

It was a nice reminder that work does not have to be serious all the time and you have to be able to laugh at yourself. Now I have to figure out how to get 'em back! Paybacks can be hell.

On another not-so-serious note... I got a canoe a few weeks back. I really like my canoe. Even better, I like that I got a really, really good deal on a used one I found from a seller nearby my house. I had the opportunity to take my kids out a couple of times last weekend and we managed not to flip it over in the lake. We have some family coming up from Florida this weekend and I think we'll take it out again. Hopefully we'll have similar luck.

Activities like canoeing are great agile metaphors. It is all about heading out in a particular direction, course correcting along the way, paying attention to your environment, and adapting as you go. You have to communicate with your partner to get the canoe going in the right direction and to establish a stable velocity. You need to collectively maintain balance so you don't tip over. Sounds like a good blog for another day.

Life is good! Thanks for listening :-)

 Subscribe to this blog

Subscribe to Leading Agile

The Agile Elevator Speech

Okay… so you find yourself in the elevator with your CEO. She asks about the agile project your team is piloting. She wants to know what this agile stuff is all about. You have 30 seconds... go!

You begin by stating that agile is basically three things: a set of engineering best practices that allow for rapid delivery of high-quality software, a project management process that encourages frequent inspection and adaptation, and a leadership philosophy that encourages team work and accountability.

You go on to say that success in today's economy requires us to respond quickly to changing market conditions. Agile processes allow our teams to meet the changing demands of their customers while creating environments where top developers want to work.

Your CEO is intrigued and invites you to walk to her next meeting. She wants to know more. Mission accomplished.

 Subscribe to this blog

Subscribe to Leading Agile

Scrum Project Management as a Simple Rules Framework

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves" - Ken Schwaber and Mike Beedle, Agile Software Development with Scrum

The Scrum methodology is elegant in its simplicity. It teaches us that when processes are not stable, and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. We must rely on observation. We must adjust the processes as we go and guide them to create our desired outcomes. Using this philosophy as its basis, Scrum is founded on three simple principles: make everything visible, frequently inspect outcomes, and adjust the process as necessary.

People really like simple messages and Scrum delivers in spades. Scrum is easy to communicate and the practices are rather straightforward and easy to implement. You can put a single diagram on a single page and talk someone through pretty much everything you need to know. There is power in the simplicity of the message and that has been a major factor in Scrum's rise as the de facto agile methodology in use today.

The simplicity of Scrum can be deceiving. That simple, straightforward message comes at a cost. Scrum is not all there is to software development and it's not all there is to good project management. If we are fortunate enough to have a group of really great developers, a fully engaged product owner, and a team that can operate with some degree of independence from the rest of the organization; the simple messages of Scrum are a great way to lead a project. The quality of the team allows you to get away with a barely sufficient methodology.

What about when our context is not so simple? What about when we have to develop complex systems architectures or work with a tightly coupled legacy system? What about when we have multiple teams distributed across the globe? What about when our product is an integration of several different products, each with their own product owner? What about when we have to deal with procurement or complex human resource concerns?

Scrum is silent on these issues.

Scrum abstracts these answers behind the team's ability to "devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves". While we are beginning to answer some of these questions, Scrum doesn't really give us much guidance on how to pull it all together. There is clearly more to the story than Scrum is prepared to address.

You know what though? That's okay.

It's okay because Scrum is broad enough to provide simple rules for one set of problems and a framework to handle more complex issues (and incorporate more complex strategies) as our teams need them. The simple rules of visibility, inspection, and adaptation don't break down. They have no geographic boundaries. They don't care about the size of your team or the expertise of your team members. They are about how we are going to control our projects in the face of uncertainty.

Scrum is a barely sufficient, simple rules framework for developing great products. It gives us space to apply our knowledge and skills and the freedom to adapt to our surroundings. We just need to be aware of what Scrum leaves out and be prepared to fill in the blanks. That said, I would rather be given a framework for adaptation than a heavyweight methodology. Very seldom in software is there one best way to do everything. Our processes should not assume otherwise.

 Subscribe to this blog

Subscribe to Leading Agile

Strategy as Simple Rules

"Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior. " - Dee Hock, Founder and Former CEO of VISA International

My wife and I help run a small private school in our spare time. That pretty much means that we don't have much spare time left for anything else. Creating this school has been a great learning experience and can be very rewarding. It can also be very difficult at times balancing the competing needs of all our school families. It has taught us many lessons about what you can accomplish if you put your mind to something, are willing to work hard, and are willing to adapt.

When we started this school, the founding members decided that we value small class sizes and affordable tuition. This philosophy has proven to be a key differentiator for our school and has allowed us to more than double in size over the past year and a half. That said, a business strategy that calls for fewer customers and less revenue can be a little risky. As you might imagine, we have to run a pretty tight ship to keep our little school afloat.

Regardless of the challenges we have faced over the past several years, we have always come back to the idea that we must have small class sizes and affordable tuition. When we are tempted to add more students and ease the financial pressure, we think back to why we founded this school and what makes is special. When considering a tuition increase to provide more services, we think about our promise to keep tuition affordable.

These simple rules have formed the basis of what has become a pretty complex strategy. The rules give guidance to the kinds of teachers we can hire, how we moderate our service offerings, our organizational structure, and our recruiting. The rules form the basis for both our short term and long term growth plans and ultimately shape our vision for the future.

In short, the rules provide a framework to guide our more complex day-to-day decision making.

Even though our school is a non-profit, some days looking more like a ministry than a business, we exhibit all the characteristics of a small startup. We are learning our market, we are learning our customers, we are learning our employees, and as leadership, we are learning each other. It is impossible to predict everything that we will encounter along the way, so by necessity, we have to be open to change… willing to adapt.

Our growth this year has been very challenging. It has stretched some of us to our limits with regard to what we are willing to personally sacrifice to make this school work. People are unpredictable and our school is full of them. It is very tempting to want to put rules in place to manage that unpredictability. We have struggled to stay focused on keeping things simple, to engage people in a way that is empowering and affirming and makes them want to be a part of our school.

We are learning, we are trying to adapt, and to that end, we are extending our simple rules strategy.

Right now we are working to identify our key roles and our key processes. We are looking for a few simple rules to guide how each one operates. Just like we have a few simple rules that influence how we manage our business, we are looking to identify a few simple rules to give direction to our staff and volunteers as they manage their day to day activities. The idea is that as we grow, we want to empower more people to be in charge of more parts of our school.

As leaders, we create opportunity and provide direction. The simple rules will give our team guidance on how to operate in alignment with that direction. Just think what we can accomplish if we are able to tap into the power and creativity of our entire school family; to allow our teachers and volunteers to make decisions, to adapt to their immediate surroundings, all the while staying in alignment with the direction we have set before them.

I think that is pretty powerful stuff and I am excited about what we will certainly be able to accomplish.

More on our school at: http://www.hopespringscs.org

 Subscribe to this blog

Subscribe to Leading Agile