Results tagged “agile project management”

Rui Afonso of Hyfas spoke about the key success factors of introducing and succeeding with Agile projects in small and mid-size companies. In comparison, Rui reviewed the distinct challenges presented to these corporations:

The challenge we see in many Enterprise IT shops is that it is hard to get everyone across the business who touches application development 'on board' with an agile approach.  In this blog post I want to share how the CIO of one of our customers has set guidelines which help drive agile project delivery across the business.
 
The customer is a large Portuguese food distribution and consumer goods manufacturing company, with an international presence.  With nearly 25,000 employees they are used to having huge IT projects, involving multiple departments with complex requirements, large budgets and long timelines. 

Before agile, many of these projects were delivered late, over budget and in some cases actually failed.  In 2005 they became an OutSystems customer; embracing the Agile Platform and an agile methodology. As they matured in their agile practices, the CIO saw the value and today they operate under the CIO's mandate that only projects scoped with a timeline of less than three months and a budget under 300K will be approved.

What happened before the CIO mandate was put in place?  Here's what they told us:

1. They would spend two to three months in meetings, aligning all opinions in order to create a huge requirements document;

2. When they finally started developing the systems the business team had disappeared and in most cases forgotten about the project;

3. By the time the project was ready to be tested the key users had changed, the business had changed and the project delivery team immediately entered into a lengthy negotiation phase to reconcile what was delivered versus what the business really needed.

This customer states that with the agile methodology and their new CIO mandate they improved the success rate of their projects in several ways:

1. The business team is more motivated and involved as they are able to see how the projects are progressing on a regular basis;

2. The business gets to be more responsible for the decisions that shape the project direction because they see and constantly test the application;

3. The business and IT avoid the costly, wasteful exercise of building complex requirements documents because they now fully realize that they can never document every detail in a specification;

4. From very early on in the project, IT can see if the project is really what the company needs and identify any mis-matches quickly to reduce the amount of time, dollars and resources that might be wasted.

5. Even for big projects, Agile methodology is used - and forces the team to split the project into phases. This exercise divides the scope into smaller, manageable projects with incremental releases and decreased risk.

So, both for this CIO and many others, we are finding that an agile approach to application development really helps increase project success rate and reduce risks.  Even in a company like this one that has complex application needs, lots of departments and bureaucracy - agile really works! 

What are the technical leaders in your company doing to help drive agile project delivery?  Or, what would you like to see them doing? 

Share their rules, guidelines and mandates along with your ideas!  

In a recent conversation I was asked about PMBOK (Project Management Body of Knowledge) and its applicability to measuring an Agile project manager's effectiveness.  While I did not know much about PMBOK and its measurement approaches I was curious to understand the problem.  As it was explained to me, the problem was along these lines. . . . When following a PMBOK approach to measuring a project manager's effectiveness, one of the things you would look at is on-time delivery.  If the project was delivered exactly on time the manager would get a rating of one.  If the project was delivered ahead of plan then the manager would get a rating of less than one (based on how much ahead) and vice versa if delivered late.  However, when following the OutSystems approach to Agile application delivery we define a project timebox and even if we deliver all features early, we will then fit any additional backlog items into the plan and keep working until the timebox is complete.  Thus, you never finish early - you always finish on time and in most cases you just exceed your customer's expectations on how much you deliver!

So, off I went and did some research on PMBOK.  What I learned is that the OutSystems Agile Methodology, while based on SCRUM, incorporates lots of extra management concepts that align with PMBOK.  (BTW - If you are not familiar with the OutSystems Agile approach here's a white paper.)  I will leave the convergence of Agile and PMBOK for a later discussion, but in my opinion, there are lots of PMBOK practices that are applicable to running Agile projects in Enterprise IT shops. 

What I am interested in is the following - What is a good measure of an Agile project manager's success?
 
In the conversations on Agile and PMBOK I've had over the last couple of weeks I have come to the conclusion that the best measure for an Agile project manager's effectiveness is not based on on-time delivery, staying within budget, etc.  But rather a measure of a new application's adoption by the business!  Everyone I have talked to on the topic agreed with this notion of adoption but none have really offered a concrete technique for measuring adoption.  In most of the discussions the notion of return on investment came up as a solution.  However, in drilling into ROI we always came to the conclusion that while ROI is important it is not necessarily a good measure of your project manager's effectiveness.
 
So my quest for a good measure of an Agile project manger's success continues.  Everyone agrees that application adoption could be it but I have yet to find anyone with a good definition on how to measure it. Your thoughts?

 
You should follow us on Twitter here.

A recent LinkedIn question asked for advice on how to get a company started down a path to Agile and SCRUM. I thought it might be useful to share some advice and see if the OutSystems community had any ideas to add.

At OutSystems, our roadmap is strictly a guideline because companies have different methods, cultures, and management approaches. When introducing Agile, here are the steps we generally go through. Concepts and activities that are emphasized will vary based on understanding of the customer culture, organizational structure (formal and informal), as well as their prior knowledge of Agile methodologies.

1. Education - first, level-set those involved in the roll out. We found that there are many different levels of understanding of what Agile is even if people say they "get it". Part of this process is to make them actually go through the process before the project begins. At OutSystems, we have "Agile-in-a-Day" training sessions that provide participants with a hands-on introduction to help develop real understanding of key concepts and activities. If you have a project already selected, involve the business sponsor, business manager, and key business users.

2. Project Definition / Selection - Once everyone is clear on the vision and direction, a project can get started. The project may have been identified earlier but how the project is chosen or what criteria was used needs to be understood. Since this is the first Agile project, we need to make sure that risks at this level are addressed to help ensure success for both project and process. The criteria for selecting the project needs to include the solution's level of complexity, visibility, resources, and integrations.

3. Execute Project - Now we start the project by educating the target users if they were not involved in the initial Agile-in-a-day. Go through the project kickoff; explain the methodology, roles, responsibilities, timeline, deliverables, etc.; fairly standard project stuff and along the way - expunge the word "scope" from all project documents, thoughts, and discussions. Work on the backlog, feature negotiations, the sprints, scrum meetings, demos, etc. Once a sprint is done, do a retrospective and refine the processes for the next sprint and the next project. Once the solution is in production, conduct a tuning sprint. This is a special sprint we do at OutSystems to ensure 100% adoption by implementing features that will boost adoption and conducting both solution performance & platform tuning in the production environment.

4. Perform Project Retrospective - apply lessons learned to subsequent projects and refine other processes. Note that this process improvement will involve Support organizations and dynamics between project teams. One of the things we often encounter is that Support organizations cannot move as fast as the project sprints and tend to delay Agile projects. Similarly, non-Agile projects have a difficult time addressing the integrations with Agile projects. As you execute your first project, you will find that you may need to bend or even break some rules to keep your project on track as defined by your timebox. Therefore at the end of the project, you will need to work with Support and other internal organizations to establish new protocols or processes specific to Agile projects.

5. Iterate Steps 1-4 - In our experience, we found it necessary to conduct multiple Agile-in-a-Day sessions to get everyone in the company level-set on the organization's approach to Agile. Agile is a mindset change; expect hurdles and naysayers. Besides, change is always difficult even if the participants are willing, able, and have executive sponsorship.

(Unofficial #6 - Be realistic and good luck)

What do you think of this roadmap? How have you introduced Agile into your companies?