4 Enterprise Barriers to Agile Transformation

Delivering projects (both business process and technology focused) for the bulk of my career, I have found these themes to ring true as barriers to agile transformation within the enterprise:

Resource Management

While resources are cross-functional often wearing many hats, they are often part of a matrix organization and deployed to simultaneous projects at once. This creates conflicting priorities, lack of visibility, and the inability to fully participate in the day to day needs of any one project team. The Agile solution - dedicate resources to a single team. Allow resources to fully participate in the daily team interactions, forge relationships, and share accountability for the overall project goal. Dedicated participation will speed the overall delivery and ease communication barriers. Freeing the resources to move onto the next priority rather than working on several at once.

Physical Location

Large corporations (even the not-so-large) have always been fond of cubicles. Building physical walls between people for privacy. What suffers is team communication. So meetings become the main way for talking with each other. Instead, break down the walls and allow the team members instant communication anytime it's needed. Co-located team members is also a huge issue. The business often lives in one building and the technical in another. Again, creating physical barriers to communication and collaboration. Keep project teams together and break down the physical wall for the duration of the project.

Requirements

Requirements are a huge stumbling block in large enterprises. Not only the requirements themselves but the politics surrounding them. Politics such as - who had input? who signed off? when were they signed-off? are they in scope? when is a change request required? The traditional assumption around requirements is that the business knows exactly what it wants and that it won't change for the duration. Any changes are considered risks to project delivery. The agile mindset says - keep requirements light, keep them just-in-time, allow them to evolve with the needs of the business. This works because the cross-functional team is in constant communication. As requirements evolve real-time business decisions can be made based on the current state of the product. Together, the team takes input from a product owner to help craft ultimately how the product meets the goal. The product owner isn't expected to give detailed how-to requirements. Only to know what the business needs and, through a series of product demos, collaborate with the team to make the product just right. Traditionally the enterprise has encouraged a long very detailed upfront requirements gathering phase in which everything is written in documentation prior to building. This produces nice documentation that can quickly become outdated as business needs change (and business needs ALWAYS change). The project starts swirling around creating change requests before one line of code has even been developed. Stop the madness, document what's necessary to give the team a running start, evolve the documented requirements as the product evolves, not vice-versa.

Compliance Requirements

Agile promotes just enough process to get the job done. Sometimes in larger enterprises the "just-enough" becomes too heavy weight and prescriptive in the name of compliance. This is a huge misfortune and one of the largest barriers to starting and being successful at Agile. The key to compliance is a keen understanding of what controls need to be in place and what the purpose of the control is. The enterprise must provide the tools, resources, and guidance necessary for teams to be successful in meeting the controls NOT provide a detailed how-to for doing something. Education and shared accountability with actionable recourse are keys to compliance.

What are your experiences and barriers encountered when bringing Agile principles to your projects?

How to Improve Your Current Project: Comunicate

How to Deliver Successful Projects: Have a Dialogue

Talk, talk, talk, and then ... talk some more. You cannot talk enough when you're leading any type of change management effort. And that's what a technology project boils down to -- implementing a change to the way things are today. So how do you manage your change efforts? What should you talk about? And to whom should you talk? My company uses John Kotter's Eight Stages of Change as a framework for structuring the conversation with those involved in projects. Here are some guidelines for getting your conversations started.

Do your homework before you start talking ...
Create Urgency: You may have communicated the purpose of your project, but does it have teeth? Paint a picture of what happens if you don't complete the project. What happens if the status quo remains? And what are the benefits that can be realized when the project is done? Often the improvement is crystal clear to technologists, but murky for others. Especially if the project is something ambiguous to a non-technical business counterpart, such as an infrastructure upgrade or an information security tactic.

Create a Vision: Realized benefits are a great way to frame how your project will make the world a better place (at least the world inside the walls of your organization). Give thought to the bigger picture of your project, so that you can paint the "future state" for your stakeholders. Whether your project will result in internal or external customer facing deliverables, painting a picture -- early and often -- is critical for gaining acceptance.

Form a Guiding Coalition: Formally organizing internal support is extremely important, because it helps sow the seeds of change. We've all heard of steering committees. Well, let's put them to work. First, it's important to get the right people on-board -- those who will help you sow the seeds of change. Ask yourself: How can they help spread the message about the project vision? How can they help contribute to defining the vision, so that it speaks to and resonates with the needs of a particular business area or customer segment? A guiding coalition is important, but the team won't work without a sponsor, leader, or visionary enlisted for the long haul. This is the person continuously driving the vision forward and helping the project team stay the course.

Start Talking ...
Communicate the Vision: Talking about your vision isn't a one-time event done via a mass e-mail. You need a plan that identifies who, when, how, and how often they should hear your message. Look for opportunities to get your vision in front of people -- status meetings, town halls, or messages and alerts in an existing system of upcoming milestones. This is not only an opportunity to communicate, but also an opportunity to sell. And like it or not, your vision is for sale. Your buyers are the people impacted by the changes, and also those individuals whose help you need for the project to be a success.

Get others talking (and doing) ...
Empower Others to Act on the Vision: You may be wondering who is the "you" that I keep referring to in this post. It's anyone and everyone who has a role in contributing to the goals of the project. The guiding coalition helps define the vision and pushes it forward. But in order for the vision to be a reality, others need to get on-board. If people feel boxed in, not supported by management or peers, or lacking access to the necessary tools, your project will fail. Make sure the barriers are removed so others can act on your vision.

Plan for and Create Short Term Wins: This is a great way to start showing progress and proving your theories. It also helps everyone realize that their effort is valuable while keeping momentum going. Think about your project plans in terms of, "how quickly can I get something useful out?" "Useful" doesn't have to mean "perfect"; you can always fine tune later. But showing visible progress sooner, even with a few warts, will provide great insights early-on into what is really important to your stakeholders. This allows your team to correct the course sooner, so be sure to create a formal feedback process to capture stakeholder input.

Don't Declare Victory Too Soon, Sustain the Momentum for Change: We've all experienced it – the anticipation of the much celebrated release party. Celebrating milestones is important, but equally as crucial is being cautious to not signify "it's over". The real work begins when the initial visible change is released outside the project team. That's when things really get started and when it's important to keep up the momentum. Change isn't easy and it's not a static, one-time event.

Institutionalize The New Approaches: We call this "business as usual". If you are implementing something new (technology, process or both), you want it to become the new method of operation. Repetition and reinforcement makes something new feel natural, as if it was the way it had always been. So, you haven't talked enough until you feel like a broken record, and others are repeating your messages and finishing your sentences.

As always, looking forward to any comments and knowledge sharing on the topic!

Stop Wasting Money Writing System Requirements

IT has long been looked to as the technical solution providers for business problems. But the assumption that often is made is that the business problem is already well understood and the business processes that drive the technical requirements are known....by someone. I continually run into the situation where a team is beginning the business requirements definition effort and developing system Use Cases only to discover it's not that straightforward. The entire business process that the technology will support has not been thought through and there are gaps in knowledge around some areas of the business process. How can this be addressed before valuable time and money are wasted spinning on requirements? Here are a few suggestions:

Every IT project should start with business process definition. It's no longer IT's responsibility to only handle the system requirements definition side of the equation. Start thinking in terms of process steps, roles, and responsibilities. Once these are defined the role of the system and how it should behave becomes more clear. The same skill set that it takes to identify system requirements is highly transferable to defining business process. Stakeholder engagement, meeting facilitation, communication skills, clear concise documentation abilities are all the qualities of solid business AND process analyst.

Run an agile project. By adopting the basic principles and philosophy of the agile scrum framework your team can get to "doing" faster with "just enough" documentation in place to make it productive. Once the business process is well understood, create a backlog with the goals the system should allow each type of system user to achieve. Define requirements in more detail as part of each development sprint. Start the sprint with a few upfront requirements tasks then continue to refine the requirements as a team through the build-demo-adapt process. The role of the BA in the demo meetings is to capture requirements and decisions made. By the end of each sprint you can have a requirements document that matches exactly what was built. This avoids spending months in lengthy requirements gathering sessions trying to predict in excruciating detail today how you want the system to work a few months from now.

These are a few ideas that have worked well on my projects. Join the conversation! What are you doing that's worked well(or not so well)?

The Art of Software Development

My company and our consultants have been using Scrum and Agile techniques on both internal and client projects for years. Our adoption has been in an ad-hoc manner and often times behind the scenes without anyone knowing that's what we were doing. Things just got done. I have had the pleasure of taking 2 days to formally learn the Scrum framework and become a certified scrum master. I am using the training to pull all the techniques together and gain a better understanding of how to best use the Scrum theory of delivery with my client projects. During the training I had an "AH HA" moment (as Oprah puts it) - software/product development is an art NOT a science! The principles of scrum center on communication, collaboration, and using a feedback loop with stakeholders to produce a quality product in a short period of time. Notice I didn't mention anything about stages, gates, documentation, or sign-off. Not that a paper trail can't be produced along the way but Scrum is more about focusing team energy on getting a usable product out the door than hashing through getting the right requirements in a document. With Waterfall there is a certain amount of risk mitigation built into the formality of the sign-off process. If the requirements are written down and stakeholders sign-off, the risk of not getting requirements right shifts from the development team to the stakeholders. From the development team's perspective "They (the stakeholders) told us what they wanted and here's the proof". In Scrum people collaborate and come up with the requirements together. The stakeholders provide some high-level product requirements/priorities to set the direction and the team uses demos and stakeholder feedback to make sure they get it right. It's so simple and uncomplicated! The Scrum Master is really more team psychologist than Project Manager. Tasked with enabling each individual team member to speak his mind and foster a sense of shared ownership to complete the team's goal. Not pouring over the Help documentation in MS Project to figure out how to do resource leveling. Team members and stakeholders (via the Product Owner) get to communicate directly instead of through the formality of requirements documents and change requests. Imagine what is possible when everyone is collaborating and developing solutions together. All the innovation that the different perspectives can bring! I'll admit, I may be a little drunk on the Scrum kool-aid right now, but what were thinking taking the human element out of software development and communicating through documentation that quickly gets outdated?