Empowering Teams

Empowering teams is a popular topic among managers and has been a common discussion among the agile community. Team empowerment is tied to many aspects of a successful team and project. Practice shows that empowering your team members leads to the following benefits:

• Increased Ownership
• Improved Moral
• Higher Quality
• Improved Return on Investment (ROI) for Projects
• Faster Delivery

As you can see in the Dilbert cartoon, implementation of empowered teams can be met with opposition and confusion. Even when management wants to create these empowered teams, they can struggle to figure out how to hand over the control, how much control to hand over, and accountability once the team is empowered. 

How To Transition

First, it is important to meet with the members in the organization and discuss the transition. This is important to ensure they understand what your working towards and why. Often times, training and team building exercises are used to to help drive this message home. Getting buy in from the teams is the most important piece because without it, they may not accept the responsibilities and power being given to them.

The second part of this discussion should include determining the boundaries of their empowerment. There are three common ways I see managers struggling with how to set these boundaries.

• Managers tell the team "it can decide how the budget will be used," but the manager must approve any spend. This is a poorly veiled attempt to create an illusion of control. The team feels they made a decision but really all of the control remained with the manager. This is the fastest way to stop the empowerment process. 
• Another common way that manager attempt to divide the control, is to act as a liaison to the business or customer rather than allowing the customer direct access to the team and vice versa.
• The final way I see work being divided is that the team can determine how the work is being executed, but the manager keeps control of what work is being executed. 

Although these policies may sound reasonable, every implementation of these policies that I have witnessed has resulted in issues in areas like: on time deliveries (waiting for a busy manager), transitioning, and team moral. As such, policies like these must be kept to a minimum in order for the team to truly take the responsibility that the management is trying to hand them.

Finally, once the team has been trained and the boundaries established, it is important to let the transition start immediately but remember even the change to the new model should be driven by the team, approaching the transition in the way the team feels most comfortable in.

Management of Empowered Teams

One of the most common issues I see in management of empowered teams is "meddling". Managers typically have two common concerns that leads to "meddling" in the project which undermines the empowerment of the team.

• The manager has a concern that the team will not for fill their obligations or they will exceed the timeline or budget provided to them.
• The manager is unsure of what his/her role would be if the control is handed over.

These concerns are legitimate in a traditional role, but when you empower teams you empower them to succeed or to fail. As such you need to give them the slack to come about the work in the way they see fit which may not align with your thoughts as a manager. To help a manager be more comfortable with this, there are reports and data that you can request on a regular basis. This data should be minimal and non impactful of the team. Think of raw data that you as the manager would then parse through and/or format to your liking. In agile this is most typically a list of committed stories at the start of a sprint and the burndown as the sprint progresses.

So what should the manager be doing if the team is empowered and self organizing?  Empowering teams is not easy and just like anything requires support and maintenance to keep it going once you have the team. As a manager of the empowered team, your role will shift to focus on the following:

• Removing roadblocks
• Mentoring team members
• Training and growth plans for team members
• Conflict resolution
• HR items
• Marketing team and output
• Removing non value added tasks from the team

Empowering teams may be a change from what organizations and managers are used to doing, but it is where companies need to move given the desire to flatten organizations and work in a more lean, team focused manner. 

Execution is your skill

I was talking with a relatively new but successful project manager and he said something that took me back. His comment, "I am not sure project management is for me, I mean I am just losing my skills." As I questioned the comment it was clear that he did not value the skills that he was developing compared to those skills of his previous technical role. This conversation is one I have had before and comes up frequently when we talk about how project managers contribute to the success of projects and why a project with a proper project manager is more likely to succeed. My answer:

As a project manager, Execution is your skill!

So what does execution look like?

If you go to an artist, and you ask them about a piece of work they are working on they are likely to tell you, "it is not done until it is done". How do you know when it is done? "I will just know." Well as a project manager, this is never the correct answer.

Execution is the ability to organize around a goal and lead someone (like this artist) or a team to what is considered completion (finished work). 

Execution sounds easy, but if you look at the artist example, they don't even know what the finished result will look like. And what happens if you have 30 artists with 100 pieces of work and then they need to put it all together at the end? Most of you are probably already thinking about how to break the work down. Creating a blueprint or a plan for how each of the 100 paintings will go together perhaps creating a "theme" to help guide the work to ensure that it will all go together. Perhaps you are thinking of all of the requirements gathering questions you would ask like what colors, due date, or budget. If you are thinking about any of these things, you are practicing your execution skill.

Executing is:

1. Organizing the work in a logical manner
2. Sizing the effort and understanding the requirements
3. Keeping yourself and the team focused on the end goals
4. Delivering value to the customer and business
5. Enabling the teams to succeed through any reasonable means
6. And sometimes... getting out of the team's way

What is the value of execution? 

In Ram Charan's book, "Execution: The Discipline or Getting Things Done" Ram says that, "70% of strategic failures are due to poor execution of leadership..." As a project manager, you are the leader for the project and the one affecting change in this statistic. This is your value statement to an organization.

Here are just a few of the benefits that businesses get out of executors:

1. Shorter time to market
2. Smaller but more valuable deliverables
3. Features more closely aligned with the needs of the customers
4. Less waste and rework
5. Better alignment to strategic goals

Execution is a valuable because it is how visions are brought to reality. Organizations value this because timely arrival of strategy can make or break their company and as company dynamics are changing this is becoming more valuable.

It used to be just being in a market was enough for a company, but now companies are charged with creating new markets and products. This type of thought leading work fits nicely with the artist reference above. As the creative aspects in products and business continue to grow, the need for executors will continue to grow as well. If you can come in and apply your execution skills to ensure a specific product is first to market or that a new efficiency gets into production before the competition, businesses are looking for you.

Top 10 Activities for Project Managers

In today's world, project managers are responsible for an increasing number of things. While this shows progression in the career and growth of the project managers, we need to remember the core activities that project managers are accountable for. These activities are activities important to the success of the project and of the team, however I am increasing seeing organizations prioritize reporting, data gathering, and office politics over these critical activities.

1) Act as the Communication Hub
In my opinion, communication is the most important thing a project manager can do. As the communication hub, the project manager gathers all of the relevant project and team data together and parses through it to provide a concise and clear message to the team, stakeholders, and management. Dissemination of this information is up to the project manager and the organization, but the actions of the most skilled communicators are easily verified by asking any stakeholder, "how is project X doing?" If they have to pick up the phone and call the project manager, this area needs work.

2) Collect and Review Documentation
When it comes to documentation, let's ignore the discussion of valid and necessary documentation for this blog and rather say any documentation that has been deemed "required" is necessary for the project manager to collect into a central repository and review/confirm complete. This is to say the project manager is not responsible for the content, but rather the storage and existence of the document.  Often times, documentation is pushed to the sideline in favor of delivery, when this happens the project manager should track and ensure completion prior to completing the project.

3) Facilitate Meetings
Project managers are not necessary in every discussion that occurs on the team, but it is the project managers responsibility to facilitate the meetings. Facilitation is not simply taking notes, but rather prepping an agenda, ensuring the right audience, driving the teams to value adding conversations, and a little bit of note taking at the end. Why you ask, see item 1. When a team is not communicating effectively it may become necessary for the project manager to step in and force the communication. This may be in the form of daily standups or weekly status meetings. One of the best ways for a project manager to force communication is to put the team into a meeting and FACILITATE it. Proper facilitation will also drive shorter more effective meetings, but more on that some other time.

4) Lead the Team
Leading a project team is not always easy, but it is critical that the project manager not simply drive for tasks to be completed, but really lead the team forward.

5) Ensure Follow-ups are Done
Without this activity, things "fall between the cracks" and commitments don't get met. The project manager should track these actions and make them part of the project plan. Most of these types of follow-ups are

6) Resolve Conflict
Over a long enough project, you are bound to find conflict in the team and/or with management. The project manager should take an active role in reducing and resolving this conflict.

7) Look Out for Roadblocks and Issues
Part of our role should be to identify any broken, inefficient, or ineffective processes that we encounter in our day to day. These items cause a problem and potential delays in our projects. We may not always be able to correct the inefficiency but at the very least we should be documenting it in a lessons learned. However, when possible we should be driving for correction. After all, if it is a problem for you and your project it is a problem for someone else as well.

8) Process Improvement
Project managers are in a unique position to see processes that effect delivery of a project. Sometimes process changes seem benign but when applied at the project level, result in a significant impact to the project deliverables. As such, the project manager needs to advocate process improvements from this perspective.

9) Continually Look Ahead of the Team
As the project moves through execution, a critical part of the project manager is to remove roadblocks and impediments for the team. Looking ahead will allow the project manager to remove these roadblocks before the team gets there. Think of it like this: The team is a locomotive moving down the track. If you slow it down, it takes a lot of energy (brake power) to slow the team and then it takes a lot of energy to get the team moving again. So any work a project manager is doing before the team gets there, will go a long way in keeping the momentum.

10) Act as Marketing Department for the Team and Project
Bad news travels fast, good news (or team successes) can go unnoticed. Why is that? Because when something goes wrong, someone, typically management, has to get involved to provide corrective action, whereas a success required no additional work or action by management. The project manager needs to be in front of management, customers, and stakeholders championing the successes of the team and leading the celebrations. Doing this well, increases moral, teamwork, and leads to greater outputs in the future.

I would love to hear from everyone else, what are the top critical activities you want/need to see from project managers? Project managers, what are the things you do that you feel are the most valuable? Is anyone feeling the pressure to spend time on things like office politics instead of your project? What are the things and how do you handle the request?

Driving Process Improvement as a Project Manager

The primary delay in companies today, are processes that don't align with the work being done. This happens for a variety of reasons from the process being out of date to well meaning poorly implemented changes to a process.

As a project manager, we see the effects of these ineffective, inefficient processes daily. We see these things when our projects take longer, we have dependencies where the work waits on the process or things are delayed for an artificially imposed dependency. To improve our chances of success and the success of other projects in the company, we should be identifying and working to resolve these process issues as they are identified and outside of the flow of the project.

If there is not a process improvement team inside your organization, the PMO is a great a place for this responsibility. If you work in an organization that does not have a formal PMO, I would suggest taking the initiative to spin up a pet process improvement project led by the project manager. This should be something that goes through a formal SDLC with requirements gathering, prototyping, development, and analysis after the change. Many people will talk about the DMAIC process most well know for its place in Six Sigma which is a great process, but may be overkill depending on the size of the process you are trying to improve and the maturity of your organization. As such, unless you have a formal process improvement team, committee, or initiative I recommend the approach below.

If you don't already have some areas that need improvement, start with looking at your current processes.I have found the three areas below to typically be the areas with the largest opportunity for improvement. When evaluating them, look for places that process is driving the work rather than work driving the process. For example, some organizations require code review before the code goes to testing. This process typically takes days to get on the schedule and results in the code siting in a queue and waiting since it had to be done before the code review could be scheduled. Could you adjust the process so that code review can be requested or scheduled in the future? Could we change the code review to not be a stop and wait? Perhaps the code could continue forward to the test environment and code review could happen later (this may produce technical debt).

1. Testing
1. Is your testing automated? 
2. How do you regression test?
3. Do you have a full test environment? 
4. Who executes your testing?
2. Release Management
1. How do you migration code from one environment to the next?
2. Who is responsible for production releases?
3. What is an acceptable level of bugs released to production?
4. Are there established release windows?
3. Requirements Gathering
1. How detailed do you require your requirements?
2. Do you require a phase gate before leaving requirements gathering?
3. What is your system or approach for requirement changes?

Unless you have the support of your organization and management team, I suggest that you select the single biggest value (most time saved) and focus on that for your first process improvement and only work on one at a time.

There are entire process improvement methodologies out there that you can use to execute process improvement (Six Sigma, Lean, Business Process Improvement, etc) but here is a simple step by step for your basic process improvement:

1. Select process for improvement and create a step by step process map (example)
2. Schedule a review meeting with the concerned parties and review the "as-is" process
1. Remember that some of these people may of had a role in the creation of the now out dated process, so be nice!
3. Confirm the process as accurate and then discuss each step and what is the value of the step
1. Really drive to understand: What value does that step brings to the process? 
2. Pay close attention to why each step happens in that order. 
4. Looking at the process from delivery to the down stream process as your goal, identify how you can make that happen faster. 
1. The items such as documentation are still valid, but why can't they occur after the product or item is delivered to the downstream process? 
5. Work with the team of concerned parties to re-organize the work and remove any tasks possible.
1. For example, do you have to stop and wait for an approval or can the work continue while the approval is happening? 
6. Test small scale, with a single project for a few weeks.
7. ITERATE! Don't be afraid to carve to much off and realize that you need to add some back. 
8. Once the team is comfortable with the new process, make sure it is well communicated to everyone otherwise adoption will fail. 

Glossary of Agile Terms

It was suggested that I level set some terminology before I begin writing some more of my detailed posts about Agile. As such I have put together a glossary for your use. I am going to be posting a series of Agile content so if you have any questions about what I mean with a reference you can refer back to this post and get clarity. You will find many of these terms defined in a variety of ways on the internet, but when I use them I mean the definition below. I will try to use links to these terms when appropriate in my other posts.

Agile

A software development methodology developed by Ken Schwaber and Jeff Sutherland in the mid-1990s. In short, Agile is a way to execute a project where you prioritize the highest value items of the project and work on them first. To enable this, the cross functional team works closely with a lead (product owner) from the business team, valuing the communication and relationship over a formal requirements document.

Agile Estimation

Features are estimated in terms of there size relative to one another. This is achieved by an approach known as “planning poker” that involves the whole team. Benefits of this approach include the sharing of knowledge across the team, increased consistency through whole team involvement and accuracy of

planning through track record of delivery. See also ‘Velocity’

Backlog       

A partially or completely ordered list of work items in the form of user stories or tasks.  Backlogs exist at multiple scopes in the planning onion, most notably at the levels of each product (line), each release and each sprint.  Effort remaining at any level of backlog can be tracked in the form of burn-down.  (See below.)

Burn-down

A graph of progress over time that represents either ‘Velocity’ or work effort completed.

Calendar Day

The total hours for a give day, which is 24 hours.

Daily Scrum / Daily Stand-ups

To keep the team synchronized, there is a 15-minute meeting every day. Each team member doing work answers the questions:

            What I did yesterday?

            What am I going to do today?

            Do I have any roadblocks, and what are they?

Demonstration / Sprint Close-out / Showcase

A showcase of the features developed during an iteration. This can involve product owners and other stakeholders. Serves as an opportunity to identify new features or change in priorities.

Duration

The number of work periods (not including holidays or other non-working periods) required to complete an activity of other project element. Usually expressed as workdays or work weeks.

Effort

The number of labor units required to complete something (an activity or task, a user story). Usually expressed as ideal engineering hours or days, staff hours, staff days, or staff weeks. Should not be confused with duration.

Epic

A very large user story.  Initially product features can be described using an Epic, User Story or stories.  Epic user stories are decomposed at the appropriate time so they can be estimated and accepted into a sprint.  Epic User Stories are sometimes confused with Features or Themes.  While Epic User stories go away, features persist with the product.

Feature

A feature is a tool used to segment a product.  Features add value (functionality) and address specific needs of product users and stakeholders.  Features are useful for scaling agile.  For large initiatives, a Product Owner could decide to allocate a feature or features to a particular Agile team.    Features are sometimes confused with Epic User Stories or Themes.   Epic User Stories go away once they are decomposed.  Features always remain as a way to describe a segment of the product.  It's good practice to associate every user story with a feature.

Ideal Day

The sum of all task hours spent in any given day.  The normal amount is 6 hours of time per day.

Information Radiator

A visual information radiator can be a story board, which can be created with note cards.  Each card represents a story, and has a priority, estimate, and tasks.  The minimum headings on the board should be the following:

Product Backlog

Release Backlog

Sprint Backlog

Stories in Progress with in progress tasks

Completed Stories

Accepted Stories

Burn-down chart

Release Planning Process

The release planning process is essentially concerned with populating, ranking and sizing a backlog of value-based stories for potential delivery during the release.

Retrospective

An opportunity for team members to reflect on the previous iteration and adapt according to lessons learned. This meeting should provide an open forum for discussion and communication among the team members. The only items discussed outside the team for this meeting are the ones agreed and documented. 

SCRUM

A term for a specific type of play in Rugby that is now used to describe a type of agile software development that focuses on making each iteration a mini-project wherein each iteration  holds it's own requirements gathering (sprint planning), design, test, and build. SCRUM recognizes other critical project factors such as team dynamic and explores ways to address these in the process. 

SCRUM is the most common type of Agile used today and the terms are increasing used interchangably though it should be noted that is incorrect as there are several other types of Agile.

Scrum of Scrums

A meeting in which all Scrum masters report up to one lead Scrum master a weekly update on the respective teams.  These meeting are no longer than 5 minutes per team, but can include as many a 8 teams.  A company that has many dependent projects running concurrently would use this approach in addition to the normal Scrum process

Sprint

Sometimes called an ‘iteration’, is a distinct set of time-boxed activities conducted according to its own plan and evaluation criteria, that results in the delivery of releasable product and or system features.  Typical sprint lengths are 2 weeks beginning on Wednesday ending on Tuesday.  Sprints should never be more than 4 weeks long.

Spike

A time boxed task or tasks performed by a team member with the intent of delivering enough information to estimate a story, which was not estimable before the spike was created.  More than one person can work on a spike, but the duration of the spike should not be longer than one sprint.

Story Point

A unit of measure for expressing the overall size of a user story, feature, or other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one.

Task  

A development activity in support of realization of a User Story within a sprint.  A good sizing for a task is something that a single team member can achieve in around half a day or less.  Sometimes longer tasks can take up to two days, but those would normally be considered oversized for most purposes.  This is where the 12 hour maximum is set as a standard.

Technical Debt

When you borrow money that you don't have to buy something today under the expectation you will have the money to repay it in the future, that is called debt. Technical debt is merely creating code or cutting some corners in the development process today under the expectation you will have more time in the future to correct this. The work that must be redone or repaired in the future was typically put in place to meet a business need (such as release schedule). This work must be completed before the project can be considered to complete. 

Theme

Themes are used for Product Road mapping, specifically at the release level.  While Features are used to describe product segments, themes are used to describe related user stories.  These stories may be associated with a single feature, but more likely cross several features or even products.  For example a product owner may decide to roadmap a themed release around security, performance, or a new user interface widget.  In these cases the high value user stories associated with each theme across all features would move to the top of the product backlog.

User Story   

The most common form of an agile requirement, which initially provides a "placeholder for a conversation" about what would be most valuable to a client stakeholder and which evolves to provide more detailed insight and objective completion criteria (including or especially test cases) as the time for its realization approaches.  A user story should take less than one iteration to realize fully and be accepted by business stakeholders via the Product Owner; see Epic User Story above.

The user story should include an estimate and a priority.  The estimate will be based on work effort, complexity and risk. User stories are typically worded as follows, "As a "role or position", I would like "the service to do something". 

Please remember that the something defined should not be technical but rather written in normal language such as "As the customer, I would like to ensure my data is protected from unethical use and hacking."

Velocity

A measure of a team's rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the sprint. It the team completes three stories each estimated at 5 story points, their velocity is fifteen. If the team completes two five-point stories, their velocity is ten.

Agile ≠ Fast

If you look up "agile" in a thesaurus you will see terms like: nimble, spry, zippy, and quick. However, in today's business, agile is used to describe a way of executing a project where you prioritize the highest value items of the project and work on them first. To enable this, the cross functional team works closely with a lead (product owner) from the business team, valuing the communication and relationship over a formal requirements document.

This type of project management has become increasingly popular over the past several years and "agile" has become a buzz word heard throughout companies everywhere. Originally built for software development, agile practices are being leveraged for every facet of IT and other areas inside companies. We could spend hours debating the value of agile or waterfall project management, but for the sake of this blog, we will summarize that both are valuable and have their places.

The issue has become that while agile is becoming a common term and the victories of agile processes are becoming more and more available and broadcast, management looks to implement these processes into their organizations. This sounds like a great win for the agile community and like a solid direction, but all too frequently management is taking their definition from the thesaurus and are looking to agile to complete their project faster. The reality is that agile uses iterative development and breaks work down into smaller chunks that allow the high value items to be delivered first.

Done correctly (we will define this in a future article) agile will result in high value being delivered first and then lower value being delivered later in the project. Agile will also provide the ability to quickly adjust to the changing business needs and values by allowing the scope to shift from iteration to iteration. But to truly be faster, it is the lean processes that you implement not agile on its own. These processes are frequently overlooked by management who instead focuses on this mystical all saving agile to fix their problems. While I personally believe agile offers a lot of benefits a greater benefit would be had by leaning out their existing processes before they move to agile. 

At the end of the day, agile is another way to organize and execute on the work. While agile delivers high value items first and faster, the entirety of the project will typically last as long if not longer (depending on requirement changes) as a waterfall project. To make your process faster, you have to start by evaluating your processes and working on improving them. After you find a way to make the individual work units move faster then you should focus on how you organize your work.