July 2009 Archives

Don't think about it - what's the one word that springs to mind when you think of "Agile" in terms of application development? Write it down somewhere.

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?

Miguel and I were recently discussing an interesting presentation by Martin Fowler and Rebecca Parsons on engaging the Architecture team into your Agile methodology.  The presentation is titled "Agilists and Architects: Allies not Adversaries" and the summary points out that "As Agile becomes more accepted, concerns from architecture groups are increasing. Traditional ways that architects engage with development groups conflict with Agile methods."
 
With architecture being a core component of the OutSystems approach to Agile application development and the role of Delivery Manager, we thought it would be interesting to share this presentation and ask the OutSystems Community how you have embraced architecture while practicing Agile in an Enterprise setting. 

For example, many of you are successfully delivering a high degree of reuse while focusing on delivering individual applications.  While OutSystems' Agile Platform provides a solid foundation for refactoring code and adjusting architecture in progress, we suspect that there are many instances where your Corporate Architecture team needed to play a role in moving the application delivery forward. 

So, if you are a Delivery Manager or Architect it is time to share your experiences of working together in an Agile application development project.  How much education was required?  Did you feel resistance? What were the lessons learned?

"Scrum brings the customer and the development team together as often as every sprint.  Because the customer is involved throughout the development process and is consulted once per iteration, the team can never deviate very far from the customer's vision." says Laszlo Szalvay in his recent Better Software Magazine article on SCRUM in which the author does an excellent job of providing an overview of SCRUM.

Personally, I couldn't agree more and I think he nails this key point about SCRUM. I suspect that most of you will be aligned with this too.

As an application development practitioner from the "old days" for me, iterative development and continuous business user involvement is the ultimate Agile truth - it's the best way to keep projects on schedule and deliver a high value solution.  

But now for the real question about customer involvement:  What happens when you don't have the right customers involved?  

Last week I was discussing an Agile project with one of our OutSystems Engagement Managers and he described this exact issue. The team was very excited to tackle this project using Agile methodology as it was going to be the first for this particular client's business area.  The business was on board, trained on Agile and they had the full support of the management who were committed to participating in planning user stories, each sprint demo, backlog settlement, etc.  

The problem was that the supervising managers were not the ones who would use the application on a daily basis and were somewhat out of touch with the processes and issues on the ground. What happened? The management team met with resistance from the guys in the trenches about the initial app - and then what? ...they changed their minds about the functionality. Ultimately this proved to be a positive experience as the Agile and SCRUM-based approach they used caught the mismatch early and the resulting app was accepted.   So, the lesson here : beware - management participation is critical but you also need the real end users to make sure you don't get too far off track!   

Have you come across this type of issue on your Agile projects? How is Agile helping your projects deliver better software?

"The uncertainty of outcome is the only certainty" This should ring true to every Agilista out there.  Let me give you a minute to think it through.  When was the last time you worked on an application development project where the outcome was certain?

In my 25 years in the IT industry the outcome has never been a given.  Oh, I tried ... we did formal analysis, with Information Strategy Plans, Entity Relationship Models, Process Models, Use Cases, Flow Diagrams, Class Diagrams and the list goes on.  But in the end, it only got us so far.  The reality was that things changed, we got stuff wrong and the result was not what was expected. 

I recently ran across a couple of great Agile techniques (with crazy acronyms) to help remedy all this outcome uncertainty that I wanted to share:

1. IWKIWISI - "I Will Know It When I See It."  For many of us this is a reality.  We have some general ideas as to what we want but will not be able to articulate it exactly. Agile's "deliver early and often" is key to addressing this issue.

2. GrASBI - "The Great Axiom of Software and Business Indeterminacy".  This term was defined in a recent CIO magazine blog by Michael Hugos titled "Agile Techniques, Agile Hype and the Essence of Agile (in IT and Business.)"  The key idea is that having a general idea of what you will deliver will get you close to the expected result, and that having detailed definitions of what you will deliver will not get you any closer.  The challenge is, of course, getting the business to change habits and recognize this truth.

We all grapple with shifting the traditional development mentality (both IT and the business) to one based on Agile concepts.  One of the hardest behaviors to overcome is this new way of defining direction and refining as we go.  So, let's overcome GrASBI, empower our application of IWKIWISI and get Agile!