Skip to main content

Tag: Project Management

Pilot an Agile Project in Your Organization

Written by Evgen Domch on . Posted in Articles. 3 Comments on Pilot an Agile Project in Your Organization

As Agile is more suitable for software development, but not all companies are ready to move from Waterfall to Agile.

Waterfall has served many projects well and is still considered as a good methodology. It is used by many companies in their day to day work. Agile is a relatively new methodology in development with many advantages, but it is not always suitable for all project types.

Let’s elaborate an approach to starting an Agile Pilot project in your organization.

Select a Project

There are several important factors to consider when selecting a project:

  • Project size must be at least 4 weeks. This time is optimal to form a full feedback and understanding of the methodology itself. The optimal maximum size of the project is 12 weeks.
  • The project should be important, but not critical. Since this is a pilot project, it is very important to consider a project without mission-critical deliverables or outcomes with a clear and specific expectation of project success.
  • Stakeholder involvement is important to involve in the project the Project Manager, designers, developers, testers, and Business Analysts. Ensure feedback from all participants is elicited and documented.
  • The project selected should go through all stages of development such as initiation, discovery, concept, design, analysis, development, testing and implementation. This gives participants a broader perspective of how Agile works from the beginning of the project to the end of a project.

Chose a Team

Perhaps this is the 2nd most important element in the first project experience is team member selection. Team members should have the skill sets and experience to be able to deliver the project outcomes and deliverables. Beginner or novice team members will have little knowledge of the potential solution will be a detriment to completing the project successfully for the first time in an Agile environment.

The team should want and be willing to implement a project using the Agile framework. Enthusiastic teams are more likely to be successful in implementing an Agile project for the first time.

Team members should also have a basic understanding of the Agile and Scrum methodologies or have used Agile and Scrum methodologies in a previous organization or role. Be careful to have a majority of team members with real experience with Agile on the pilot project. They will be able to help less experienced team members on how Agile and Scrum operates.

Formation of Roles

The next step will be the formation of the roles in the team. Key roles for an Agile team are:

  • Product Owner
  • Scrum Master or Agile PM
  • Development Team
  • Business Analyst or Customer

These roles are divided into 2 groups. Client Side and Technical. The client side, namely the Product Owner and the BA, are responsible for the creation of requirements and form them into user stories. The goal of Product Owner is to provide “Just enough” information to the development team so that they would be able to begin work on the product within the sprint.

User Stories and Acceptance Criteria

An early stage of planning is “Road Map” or sprint planning. It is necessary to plan each sprint based on the estimates provided on what it would take to complete the user stories. Since this is the first Agile project — accuracy is not what you should emphasize. Be mindful that you are still constrained by the length of the sprint. Your first few sprints will most likely have very inaccurate estimates for user stories. This will result in the first few sprints not accomplishing all the user stories expected.

Planning consists of taking the desired functionality and creating user stories to support them. Each of the user stories should have a specific set of acceptance criteria. This ensures the definition of “done” is clear to the team.

A user story is an instrument of functional description which is typically stated in the following fashion:

As a _________ I want to _________ So that_______

Acceptance criteria describes specific functional requirements that will be accepted by the business for the user story. and show specific steps to achieve the result. Acceptance criteria are typically constructed in this manner:

Scenario: Login

Given: I am on the Log in page, and the login ID and password fields are displayed
When: I am able to enter my login id and password
Then: the login button is displayed and available for me to click to start the login process

Prioritization of User Stories

Prioritization of user stories is an important part of any Agile project. As sprints are very time constrained and this is a pilot program expectations need to be set that not all user stories may be able to be delivered within the expected timelines. Prioritization of user stories will allow those user stories with the most business value to be worked upon first. Sprint 0 planning should take the prioritization into consideration when planning which user stories are placed in specific sprints.

Estimating User Stories and Acceptance Criteria

Once the user stories and acceptance criteria are created, then we are ready to estimate. Typically a T-Shirt size system of XS (extra small), S (small), M (medium), L (large), and XL (extra large). Each user story and acceptance criteria are estimated using this approach. As a pilot project, you will encounter estimates that are not very accurate. This will result in the early sprints of an Agile pilot project to not deliver all the expected user stories for a sprint.

Once the user stories and acceptance criteria are sized, they are slotted into sprints. This activity occurs in Sprint 0.

Getting to Zero

Sprint Zero is a very important event. In this sprint several things will be determined:

Sprint size is determined. Sprint size is the duration of all sprints in the pilot Agile project. All sprints should be of equal duration. Be aware that as a pilot Agile project your durations may be a little longer (such as 3 weeks) in order to assist in team members in learning the Agile process more fully). Typically sprint durations can range from 2 weeks to a month. Pick a duration that makes sense for the team and will result in incremental deliverables that will give the team a sense of success.

Plan each sprint by aligning each user story and acceptance criteria into a specific release based on its priority. Be careful not to overfill a sprint. Realistically align user stories with sprints based on their estimates. As always beware your estimates may not be very accurate. Start the first couple of sprints with a smaller amount of user stories to give your team the time to learn the Agile approach to development.

Once user stories are assigned to sprints, review the tasks needed to complete each user story to ensure the tasks can be completed in the sprint. Be aware that some task may require the efforts of resources that are outside of your team. Where ever possible ensure the tasks that are performed outside of the team are completed prior to the sprint starting. An example of this would be a DBA. A database request may take your organization several weeks to complete and implement. Trying to squeeze the database change into the sprint would result in not being able to complete the sprint fully. Instead, have the DBA request completed before the sprint started to developers can focus on the sprint without having to wait for external resources to complete tasks for them.

Starting Up

Schedule the daily stand-ups. Be sure all team members understand the daily standup and the purpose of a stand-up meeting. Put a 15-minute meeting on your team members calendars (hopefully schedule in the same room) every day with each team members covering these topics:

  • What I did yesterday
  • What I will do today
  • Do I have any problems or concerns

The scrum master will lead these meetings. Bring a timer. The is 15 minutes in length and time is of the essence. This is a problem-solving meeting. When problems are identified, immediately ask who needs to be involved in determining a solution for that problem. Then have those individuals tackle finding a solution OUTSIDE of the meeting. The amount of time per team member depends on the team size but typically 2-3 minutes is given to each team member.

Interaction with team members is important. Due to time constraints of the daily stand up and sprint a lot of pressure is put on the new Agile team member. Be sure to give them opportunities to discuss their experience and be available to offer solutions to situations that are encountered.

Acceptable Product

Acceptance criteria were established for each user story. As each user story is completed, the acceptance criteria for that user story should be validated. Make sure the team understands that user stories must be validated by the team by executing the acceptance criteria.

End of the Sprint

A sprint review and demo are conducted at the end of the every sprint. This reviews the user stories that were completed ensures acceptance criteria has been met.

At the end of every sprint is a retrospective to reveal lessons learned. This is important as this pilot Agile project will need feedback to improve future efforts and processes to help the pilot Agile project be more successful over time. An hour meeting with all teams should answer the following questions:

  • What did not go so well?
  • What still puzzles or doesn’t make sense to us?
  • What went well? What things should the team keep doing?

A good thing to keep in mind is ending this meeting a positive light. Focus on things that didn’t go well and move into things that went well. This leaves the team members with a positive impression at the end of the meeting.

The leader for the Agile project pilot will need to take steps to improve areas where things didn’t go well or areas that don’t make sense to the team. Always ensure follow-up is performed with the team on items brought forward that need improvement.

Do not try to solve the problems identified in the retrospective meeting. Assign teams members to investigate and get back to the group at a later date.

In a Nutshell

This article elaborates a very high-level set of tasks for piloting an Agile project. The structure and readiness of your organization’s leadership to use the Agile methodology should be explored deeply before starting an Agile pilot project. In setting senior leaders expectations, it is important that senior leaders have a complete understanding of how the Agile Mythology operates. Setting the expectations of senior leaders for the pilot is critical to ensure it has a good chance of success.

Good luck on your Agile pilot project!

From the Sponsor’s Desk – Transforming Projects with Architecture

Written by Drew Davison on . Posted in Articles. 2 Comments on From the Sponsor’s Desk – Transforming Projects with Architecture

Architecture has had a significant impact on humanity over the centuries, whether in the form of planned structures, environments, societies, frameworks or technologies.

In the technology sphere, architectural practices have contributed to everything from chip designs, to communication protocols to design and code repositories. Generally, things that receive architectural attention are of higher quality, cost less in the long term, perform better and receive higher levels of satisfaction from all stakeholders. But, is there an easy way of achieving those benefits on individual projects, of transforming projects with architecture?

In the following case, you’ll see how one organization used their architectural passion for slicing and dicing individual projects into their component parts, delivering better, faster and cheaper solutions while building reusable foundations for the enterprise.

Thanks to L.D. for the details on this story.

The Situation

In this medium sized financial services organization, senior technology and business leaders from the four lines of business would often hang out at a local pub on Friday afternoons. The gatherings were informal and largely social. On any given Friday afternoon, the numbers could range from two or three to more than ten. On occasion, one of the business leaders would talk about a planned project and ask for advice from the other participants. Periodically, one of the technology leaders would chat about an emerging technology and look for feedback on potential opportunities and impacts.

Over time, the informal gatherings became a vital hub for advice and sharing. Often, instead of booking a meeting in the office to discuss a planned change, participants would confirm attendance at the Friday afternoon gathering. Depending on who was in attendance, the informal discussions often revealed multiple perspectives about the project that would have a beneficial impact on subsequent planning and delivery efforts.

The head of the database group, let’s call him John, saw what was happening with the Friday gatherings and thought there would be significant benefits in formalizing the process. So he sent out a proposal to the usual attendees and suggested it be discussed at the next Friday afternoon gathering, of course. Fifteen business and technology leaders showed up, including a number of first-time attendees invited by the regulars. They kicked the idea back and forth and managed to reach a consensus – let’s pitch it to the executives. John agreed to lead the effort.

The Goal

The Friday afternoon pub group agreed to a target vision to accelerate project deliveries while reducing costs and improving development and operational quality. Their goal: a framework that would identify the business, information, application and technology components required to support a project that could be developed in parallel to accelerate one solution and be reused by others. They agreed to pursue approval of the following approach:

  1. Submit every project to a review by domain experts to identify opportunities, impacts, and shareable components.
  2. Use the review to partition the project into component parts, including business processes and functions, hardware, software and communication technology components, shareable code for business and technology objects and interfaces and components for human and technology consumers.
  3. Build the processes and facilities required to operate the review and launch exercise over time based on the individual project experiences.
  4. Above all, accelerate delivery, improve quality and deliver reusable components.

Essentially, every project could become a mini program with multiple businesses, object/data, technology and application components, built in parallel and assembled to deliver the final solution. The diagram below, initially sketched by John on a pub napkin and circulated to the attendees, became the official target.

Davison 031617 1

The Project

John and a few of the other senior business and technology leaders from the Friday pub group took their idea to the CIO. He was a traditionalist with a computer operations background. They sold him on three key principles:

  1. Technologies were developing and expanding at an ever increasing rate. He agreed.
  2. The organization’s business lines would require support for many of these technologies because of customer demands. He was already experiencing that trend.
  3. Using priority business projects to assess a technology’s viability would address the needs of the individual projects while driving infrastructure capability to serve the entire organization. He loved the idea of the IT infrastructure being ready before the business needed it. He agreed.

John, the CIO and the business leaders from the Friday afternoon pub group took the idea to the executives, one at a time. They would have to buy in for the proposal to work. The agreement was reached one after one including the CEO. Then the real work began.

John and the other pub group members formed the initial review team:

  • Corporate architecture – John (chair)
  • Business lines
  • Infrastructure
  • Software development/delivery
  • Project management
  • Computer operations

There were some obvious knowledge gaps, particularly around the inter-relationships among the various points of view – for example, which business lines used which applications, objects/data, technology, etc. They decided to build their knowledge as they went.

The group started with the current year’s approved project portfolio. They sat down with the owners of the priority projects, explained the approach and asked for the owners’ support and participation. They then took the first ten projects through the process. Here’s what they discovered:

  • The process was more difficult than it sounded.
  • The group’s leaders found the process was taking considerable amounts of their time, so they started orienting and involving some of their senior staff to carry more of the load.
  • Other than the broad generalities of their vision, they didn’t have metrics to help them gauge how they were doing and how the organization was benefiting.
  • They found that some of the component initiatives launched to support a project were more expensive than the individual project could afford.
  • On a couple of projects, they discovered that the total time and effort needed to deliver the identified component pieces would be significantly greater than what would be required to deliver the project in the traditional way.
  • In a number of areas, they lacked the processes and methodologies to develop, deliver, test and operationalize reusable components.

The group’s progress and findings were communicated openly with senior management and project owners and received lots of attention at the Friday afternoon pub sessions. The group responded by tackling each issue as it arose. To tackle the issue of process complexity, they started focusing on the low hanging fruit. Yes, they left some potentially valuable reusable components on the table, but they delivered quality solutions quickly. To address the metrics gap, they started tracking components reused, the number of subprojects per project and elapsed time cut using actual time as a percentage of an initial estimate established by a subgroup of the team. They also started documenting the processes and practices that were adding value for future use.

Perhaps the biggest stumbling block the team encountered was on the cost front. They established another metric on total actual costs versus estimated cost, using as a proxy the expected benefit times required payback period. For example, if the estimated cost proxy was $750,000 (expected benefit of $1 million annually times required payback of 9 months), and the actual cost for all subprojects was $1.5 million, the total actual costs versus the proxy for estimated cost would be 2, or twice what it would have cost doing things the old fashioned way.

Obviously, they needed to get that number to 1 or less. However, in the short term, while they were building reusable components and not able to reuse a lot, they needed a mechanism to take a project’s business owner off the hook for the extra cost. The method they came up with was to establish a separate infrastructure investment fund that would pay for any extra costs above and beyond the estimated cost. The business leaders loved it. The company’s executives approved it and provided funding of $3 million annual for the first three years.

The Results

Over the first three years of this process, the results rewarded the company’s faith in the exercise:

  • A number of components reused went from zero to an average of 26 per project.
  • A number of subprojects per project went from 3 in the early days to 11 at the end of the third year, indicating much more parallel development was taking place.
  • The elapsed time reduction went from 1.3 (more time) on the first few projects to .85 (less time) due to reuse and parallel development.
  • Estimated cost versus actual cost went from 2.3 (significantly more expensive) to 1.2 (a bit more expensive). There was still some money left in the third year’s infrastructure investment fund at the end of the year.

Transforming projects with architecture!

Needless to say, all the stakeholders involved in this change were enthusiastic about the results. There were also other results which had not been anticipated. They discovered that breaking the projects up into their component pieces resulted in smaller, more predictable initiatives with fewer surprises and more reliable cost and timeline estimates. In spite of significantly more production change activity, production problems actually declined by more than 30% over the three years. As well, unforced staff turnover was down by 50%, and the annual employee satisfaction surveys showed record increases, mostly attributable to the emergence of an exciting, collaborative culture. Transforming culture with architecture!

How Great Leaders Delivered a Transformation

This change wouldn’t have happened without the weekly pub group. The participants were in a convivial environment, relaxed, and ready and willing to share some enjoyable chitchat, engage in wide-ranging discussions and give and take. It also wouldn’t have happened if someone, John in this case, hadn’t seen the germ of an idea and had the courage to shape it and present it to his group mates.

The actual practices presented here are difficult to apply on a project by project basis. Somewhat like project portfolio management, architecture needs some help from higher up the food chain. However, there are a few learnings from this case that any project manager or team can leverage:

  • Share your ideas – Don’t hesitate to look for opportunities and share your observations. Let others contribute to shaping the vision.
  • Take it outside of the office – Look for a relaxed venue outside of the office to exchange musings with friends and colleagues. A pub is a great venue but an off hours food court, a park, a walk around the block can also work.
  • Embrace diversity – Don’t just hang out with the folks you normally encounter. If you’re in IT, engage with some business staff and vice versa. Include your boss, or your staff, or the boss’s boss. Include some customers. Be open to new perspectives, different ideas.
  • Start small – John didn’t have all the answers, nor did the pub group, nor did the CIO or the executives. The germ of an idea was enough to get started.
  • Break it up – The review team discovered that there were benefits to breaking projects into their component parts beyond the reusability opportunities, including better time and cost estimates, greater predictability, better quality and the opportunity for parallel development.
  • Build proficiency incrementally – The review team could have taken six months to draft processes and procedures to help guide the way. Instead, they jumped in learning while doing and sought help when they ran into problems.
  • It’s all about the journey, not the destination – All the stakeholders signed on to a journey of discovery. They didn’t know how much was in the pot of gold at the end of the rainbow. And it didn’t matter. They’re still on the journey.

So, be a Great Leader and put these points on your checklist of things to consider on your next project so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.

5 Takeaways from Failed Projects

Written by Brad Egeland on . Posted in Articles. 7 Comments on 5 Takeaways from Failed Projects

Projects fail. It’s a painful reality, but they do. And we can either learn from them or keep repeating them.

Unfortunately, we often repeat our mistakes a few times before we realize they are mistakes and may be the underlying causes of the failures. For me, this list of five is a good start in realizing what I needed to learn and change about mine and my teams’ project delivery processes. As you read my list of five, please consider what your list might look like.

1. Always Conduct Lessons Learned

This one is hard, I realize. A 2010 survey I conducted with project managers and their teams indicated that 57% either never conducted lessons learned sessions or performed them on fewer than 10% of their projects. People move on to their next assignments, and it just isn’t enough of a priority to make these sessions happen. That is unfortunate because another survey I conducted indicated that 46% of project leaders felt future project failures could have been avoided if they had been conducting lessons learned sessions rather than avoiding them.

2. Peer Reviews of Deliverables Are Important

I once had a project fail almost entirely because we weren’t conducting peer reviews on project deliverables. You may be saying to yourself, ”peer reviews..why?” Well, here’s why. My very skilled and experienced but also very thinly stretched (across 3-4 projects) business analyst on the project was producing a

Functional Design Document (FDD) – an important document on a complex technical project Not a huge project, but not a small one either…about a $350,000 implementation. Because of a glitch in the PDF program, he was using; we sent 3 error-prone documents to a very frustrated client before we got it right. Then we peer-reviewed every deliverable after that and on every project I’ve managed since then. Small oversights can lead to big client frustrations. Your customers start to think of you as sloppy and question what the overall end solution is going to look like. Don’t give them a reason like this to start lacking confidence in the delivery team’s abilities to get things right.

3. Communication is at The Forefront of Project Success

Miscommunication can sink a project quickly. Communication is Job One for the project manager. Poor or lacking communication leads to misinterpreted requirements, re-work, gold-platting (over developing a solution thus costing extra money beyond what’s budgeted for the task), and poor decision making. All of these can cause projects to fail in mid-project or to cause the rollout of a solution that the end users can’t use properly. Or it may cause a solution to go to user acceptance testing (UAT) that isn’t really ready for UAT. Trust me, the last thing a project manager, business analyst and tech team want to endure is a very painful customer user acceptance testing experience. It’s no fun. It’s costly. It causes great customer frustration, dissatisfaction, and a quick loss of client confidence. “Back to the drawing board” is not a phrase that the project team wants to hear. And your senior management won’t be too happy either. It is a big fail.

4. Make Sure Your Chosen Tool or Tools Can Do The Job

Make sure the project management tools you are using can get the job done. Some projects require heavy bug/issue tracking. That’s great if a spreadsheet can do the job, but if it can’t you need to tie change orders and pricing into it – then you may be running the project with inadequate project management and reporting tools. As you and your team assess the landscape of the project – including the requirements for managing the budget, the issues, the changes and scope, and the risks. Be thinking about what reports are going to be needed and what your current project management tool can handle. You may need to research some new options and chose a different direction for managing this particular project. Spending a little more money or taking the time to use the right tool can mean the difference between success and failure or at least on time and on budget delivery both of which tie into customer satisfaction and a successful project delivery.

5. Balance Customer and Senior Leadership Input When Making Decisions

What the customer thinks they need or want may not actually be the solution to their project needs. That’s why planning is critical, and you may have to tell the customer “It’s bigger than you think.” Step back with your team and assess what the business processes are and whether or not this “need” from the customer is the real problem or just a symptom of some bigger project that needs to happen.

The same goes with your own senior management who may sometimes give you direction on a project or how to handle a customer or key decisions. Do not blindly follow. I did on two occasions, and it ended up costing us two projects worth a combined $3 million. It was painful. Had I openly questioned my PMO Director’s direction on the projects and the decisions he made for these two projects, then we might have been able to save them. Hindsight is 20-20, indeed. But I’ve always been a customer-first kind of project manager and those two projects really confirmed why I am that way. If you are the project manager in the trenches with the customer and team on a daily basis, you are likely in a better position to make good decisions that will benefit the project the most. You see all angles, not just the best interests of your organization. Consider everything and don’t blindly follow. If something doesn’t feel right, say it then and not later when it’s too late.

Summary

Project failure happens. It isn’t always a complete failure. Take that project mentioned above where my team and I delivered the error-prone Functional Design Document three times before getting it right. We eventually handed off a solution to the client. But they weren’t excited about it, it was late, and they never ended up fully utilizing the technical solution. It went about 6 months and $150,000 over-budget. It was for a major airline and could have been a great success story. That one deliverable certainly wasn’t the reason for the failure, and it rested on both sides – with my delivery organization and with improper customer expectations, training, and planning. Still, I would not consider it a success.

What about our readers? What would you add to the list as some key causes of project failures or behaviors that can result in poor project delivery? Please share your thoughts and experiences.

Team Leadership on Agile Teams

Written by John Yorke on . Posted in Articles. 9 Comments on Team Leadership on Agile Teams

Yesterday, I had two people both of whom I have a lot of respect for, independently say that having a single person in charge of a team “works.”

I was taken aback by this, partly because of the surprise that two people would say the same thing on the same day, but more so because this goes against my experience and my opinions on good team leadership. This caused me to step back and reconsider my opinion and my reasons for it. For me, there is a great pleasure in being challenged on my opinions, especially ones that I was so sure of and have given a lot of thought to.

My Experience

I have worked for other people for more than 25 years and have spent a great deal of time witnessing leadership in action. I have also managed teams myself and have coached quite a few. By a very quick count, I would say that 70-80% of team leads were poor leaders. For sure, there were a few that got the job done by force of will, by leveraging authority, or by imposing death marches on the team. The organization sometimes saw them as successful, but the teams thought them to be more like dictators or bullies.

Many team leads – often insecure at accepting other people’s ideas – simply were unwilling to see or consider any other perspective. But there were a few good or even great leaders who didn’t see management as a tool for control, but as a scaffold for building the team and achieving great things – if only these leaders could be cloned.

So I am probably tainted by my experiences, but the notion of one person in charge of the team fills me with dread. I wholeheartedly agree that the model of a single leader can work with the right person, that does not mean that it will work in most cases, or that those qualities are the norm, and it certainly doesn’t mean it will work as a model in every case. What is more likely is that those great leaders would thrive in an environment where they didn’t have defined authority- but more on that later.

I can only imagine that just as I have been colored by my experiences, my colleagues have equally been colored by theirs, but they have had the good fortune to see better leaders than I have. We will also discuss this further and why this is a good approach, and whether my instinctive reaction and poor experiences are in contrast to theirs.

Before proceeding, let’s stop here and reflect for a moment. One quote that comes to mind related to what I have said is the following by Author and Former Nuclear Submarine Commander David Marquet: “Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.”

Oh Captain

The military is often used as an example of one named leader, but there is a distinction in the military that differs from industry, and that is that they have needs that are very different to a software team. Those differences are a need for independence and a desire for expedience in decision making: Military units will often need to operate independently without contact with their parent structure.

In a business environment, it is rare that a disagreement is so urgent that it could not be referred up if there was some type of dispute. The other aspect of a military organization is that “life and death” decisions need to be made very quickly; with little time for debate or consensus-seeking.

However, even in military structures, there are examples of leaders who take the view that they are the Product Owners. This means that they will say “this is what I want to achieve, you tell me how” and then suggestions are made, and the leader simply endorses the team’s advice or at least considers it before making a final plan. Naturally, there is an element of accountability, but the trust that this demonstrates in the team is significant in empowering the team and growing it.

This notion is explored more deeply Marquet’s book: Turn this ship around. Let’s take a look at some of the principles outlined in the book.

Agile Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

We Want Conflict and Debate

In software teams, it is often the debate that produces the greatest thinking and best ideas, so stifling the debate is counterproductive to success. Having a single person making decisions smothers debate, it thwarts conversation, and it disempowers the team. If a team is overruled often enough, they will stop making suggestions, and if one person becomes so myopic in their opinions, it can make the team feel powerless and excluded. Also, when there is a defined leader they often have a tendency to lack transparency, as information is selectively shared and this lack of information also impedes debate.

In short, I believe that having a defined leader is in conflict with another Agile principle.

Agile Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Merging “the What” and “the How”

Having the same person responsible for both the what (vision) and the how (implementation) also stifles innovation. Rather than the team determining the best architecture and the best solution it becomes driven by a single individual. Again, this is at conflict with Agile principles, and while you may say that a good leader wouldn’t let this happen, experience and evidence speaks to the contrary. Power corrupts, and if someone has the responsibility and authority, it becomes hard for them not to use it, especially if he or she perceive the team is making a mistake. And if teams are prevented from making mistakes they will stop experimenting.

We Want Balance

Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors. It is rare or at least uncommon to have a single individual that is able to understand and balance those conflicting elements effectively on their own. More often than not, a single individual prioritizes one above the other, driving to a deadline, or gold plating a solution. In some instances, any other single aspect usually becomes prioritized at the expense of the rest of the project needs.

I believe that a model based on shared leadership and shared management between multiple roles solves many of these problems. Having someone focused on “the what,” others focused on “the how ” and someone else focused on team improvement and consistency might create conflict (deliberately), but it might also create balance and harmony, and it becomes a catalyst for (great) debate.

We Don’t Want a Silo

If we make one person responsible for the direction, implementation and team growth, we are putting all our eggs in one basket. If this person is on leave, out sick, or leaves the firm, his or her absence can have serious repercussions to the project’s success. There can be so much knowledge tied up in one person that they become indispensable, and of course, this puts all at great risk.

Problems with Shared Leadership

However, I would be remiss not to consider downsides to a shared leadership model. First and foremost, there is a cost. For small teams, it may be difficult to find team members that have a natural affiliation to the balanced leadership model, with part-time Product Owners or coaches/scrum masters. It can be a tricky situation when these roles are not officially named, but the responsibilities are shared.

But even then, I would say that calling one person “Lead” or “Manager” can again be destructive. And the notion of combining Coach with Product Owner and implementation into just one named role can lead to dysfunction. In many respects, I wonder if the cost of additional named roles is worth it just to prevent the dysfunction a single leader creates. If the team is too small to warrant the explicit roles, then get rid of named roles entirely. If a team is that small, then naming a leader should be unnecessary and should be self-organized within those boundaries.

This may sound hypocritical, after all, I have spent a good proportion of my career with leader or manager in my job title, but my experiences have been one of an internal conflict in that role. As a Software Development Manager, you become the de facto Product Owner, Project Manager, architect, and team coach.

But there’s often pressure from somewhere, and normally that pressure was to the detriment of the team. In the past, when I challenged it, I did so at personal risk.

Customer and senior management pressure to deliver, cuts costs and drive timelines, which mean that team growth becomes secondary, and team welfare is deprioritized. This leads to making a safe place for teams to learn from mistakes very difficult. Some of that is company culture, but I believe much of that comes from the expectations of responsibility, and bestowing leadership carries pressure and expectation (sometimes real, sometimes assumed). And speaking as someone that has experienced it, I’d rather share that responsibility.

Conclusion

So after reflecting on my interaction with my colleagues about having a single person as a team leader, I am even more convinced that a named leader – whether it be a Team lead, tech lead, manager, senior or nerd wrangler – goes against the principles of Agile. While deconstructing that conversation, I believe more than ever that it undermines self-organizing teams and leads to dysfunction and imbalance. There are exceptions, and there are some team leads that are effective, but I wonder if they would be just as effective, or even more so, in a self-organizing team structure. That being said, there are much more examples of ineffective team leads where power corrupts, and they dominate the team, stifle debate and innovation, and disrupt or impede team growth.

In my opinion, the best leadership model is a balance of “What, How and Team Improvement,” and the more people that share those responsibilities, the better. In practical terms, I’d like to see a team with a Product Owner to determine “the what” but a PO who actively engages with the team. A coach that is focused on the team’s improvement and process improvement and the rest of the team is responsible for “the how.” Within the team, there is no need to identify a senior or a leader as the team can work out decision amongst themselves without titles getting in the way. This model may come with a cost, and it may be difficult to get the balance right, but in my experience, this balance leads to the best results.

Ironically, the examples of leaders that I have seen as being successful (as measured by both results and team morale) have voluntarily and noticeably made themselves servant leaders, stepping back and inviting the team in, choosing to give away authority and creating healthy debate and healthy conflict. So if that is how they lead effectively, why not make that the model from the start?

One Final Thought

I came to adopt an Agile mindset from seeing poor leaders disempower the team and abuse teams into death marches and drive poor design decisions. I saw Agile as a method for empowering the teams and taking away abusive power from lone leaders. The stimulating of constructive conflict and healthy debate are so essential to the process that I object to any impediment to this on principle.
To my delight, in most cases, Agile has done that and so much more, in a creative environment like software, the gains of self-organized teams so massively outweigh the losses that result from a lack of a single clear leader that I am more confident in my opinion that the words “lead” or “manager” have no place in job titles on an agile team.

Keeping Your Project Team Motivated and Engaged

Written by Lisa Anderson on . Posted in Articles. 3 Comments on Keeping Your Project Team Motivated and Engaged

In leading and participating in hundreds if not thousands of projects during my 25-year career as an executive, consultant, and non-profit leader…

it is apparent that the most important aspect of projecting success is keeping your project team motivated and engaged. It seems as though success (especially on technical projects) would stem from some highly technical concept but that doesn’t hold true. Instead, those teams that are motivated and engaged far surpass all else.

The good news is that motivating and engaging a project team is almost exactly the same as motivating and engaging employees. People want to be treated well, informed and appreciated. Here are a few of the top strategies to motivate and engage project teams:

  1. Vision and goals – One of the most common mistakes project managers and executives make is ineffectively or simply not communicating a clear vision. When employees do not know where they are going or why they are not motivated to “get there.”

    Don’t be confused. Companies with vision statements on the walls are no better off than those without a vision statement. What matters is when the project managers and executives live and communicate the vision on a consistent basis. How does the vision relate to the project? How is the project team involved and a part of this vision? Think about the following questions: Is it part of daily conversations? Does it matter? How do departments, project teams, and employees contribute to the vision? Have you translated the vision into goals? Clarity, simplicity and passion matter.

  2. Leadership that combines passion and focus – Day-to-day leadership and communications engage employees. It’s as simple as that: project managers do not have to be charismatic; they must be passionate and focused. If the project manager is energized about the project, the project team will follow.

    For example, an organization I worked with that had the most engaged employees was led by a less-than-charismatic CEO; however, he had passion, drive, focus, and integrity. Everyone knew where we were headed and which of their tasks were most critical to the current focus and direction of the company. There was no doubt what was critical. Priorities were clear. And everyone knew that it was likely that the CEO and/or other executives would stop by to discuss ideas and brainstorm about the company’s area of focus. Their input seemed to matter. Suddenly employees were engaged. We managed multiple projects at this company and had engaged project teams because they knew they were a part of something important and felt needed.

  3. Appreciation – A simple thank you can go a long way! It is amazing how much of an impact being appreciated has on a project team member’s level of engagement. Unfortunately, I’ve seen countless examples of exceptional employees who don’t receive any appreciation, but instead get negative attention at times for bringing up potential problems or roadblocks that must be tackled in order to achieve the project goals successfully. There is nothing more disheartening to an exceptional employee than a complete lack of appreciation for the results achieved.

    On the other hand, the best leaders who drive bottom line business results speak with their employees and project teams. They review goals on a frequent basis and discuss roadblocks. They show interest in the employee’s ideas and provide immediate positive and corrective feedback. The best leaders appreciate progress and congratulate success. And the best leaders with the most engaged employees give credit to their employees for successes and take responsibility for the issues.

  4. Empowerment – Empowering project teams within reasonable guidelines will go a long way. People want to feel as though they have some level of control over the project’s success – and that they have an impact. Knowing they are empowered to make decisions within specific guidelines enables motivation and engagement.

The only unique circumstance related to project teams ties to the cross-functional nature of projects. Project team members need to feel “safe” and “free” to participate in projects without repercussions from their manager (which could be as simple as working long hours to get both done without discussion). Thus, the project manager must be alert to these occurrences, talk with the managers associated with his/her team members and proactively address this topic.

Since projects will have a substantial effect on your customer loyalty and bottom line – the two most critical aspects of any business – it is worthwhile taking a few steps back to think about how to ensure success by looking at one of the most critical ingredients – team member motivation and engagement. Set aside time to think about engagement and how you can improve upon your situation (no matter how good or bad) – one small step at a time will be noticed by your project team and success will follow.