AGILE! My old nemesis.

 

I LOATH AGILE DEVELOPMENT.

Ahhhhh... that felt good to get off my chest. To be honest, Agile development is a great idea. I don't hate it, just the way its implemented. It becomes an excuse for doing less 'fluff' and more coding.

 :| Oh no, this will end badly.

In one organization I witnessed the implementation of Agile methodologies with this kickoff:

 "Ok we're going to be doing Agile now. The good news is we have been doing it all along! Yay."

They were doing the bare minimum to get by on a large scale project and now they wanted to implement Agile. What they really wanted to do was to justify their 'effort' to the client and they did! They had some daily processes in place, team structures yet documentation of the system prevented knowledge transfer. We would see, and all to often, production systems being effected by updates that did not receive full testing and updates effecting other systems because dependencies were not documented. Changing their development methodology was not going to fix their problems, especially if the information needed is never recorded let alone access.

This is a prime example of why I loath AGILE - the implementation.

DO AS MUCH OF WHAT YOU CAN… to move the project forward

This usually doesn't mean comments, documentation or planning. When done right, progress can be made and quickly. The scrums allow for progress to be track, controlled and perhaps documented. Problems can be quickly resolved and a small team can accomplish amazing results. However; if you are thinking about implementing AGILE or any other development methodology you have to think to your self - what are we looking to get out of this, what's the ROI?

Development methodologies, and I am going to generalize, are a set of steps followed during development to produce a result. This result is not, in my opinion just the final output but the surrounding documentation that supports it. If there is a problem and the developer is MIA, where do you go? In my first development job, the methodology was developed in-house and was flexible. Depending on the size of the project, certain steps would be included (ie feasibility steps were omitted when changing report formatting)

If you can answer this, then you have a better chance at picking the solution/approach that best fits your organization. There are so many models to follow during the Software Development Lifecycle (SDLC) such as recursive, waterfall etc., that you should gather a good understating of each rather than implementing what's hot: AGILE.

The ROI

The benefit of using the AGILE methodology is primarily the speed of development. With clear objectives and a team leader that can stay focused on the target, the results will be shorter development time (cost savings) and concise documentation. This is key - clear goals that are not moving targets are great candidates for this approach. If you find that the goal shifts frequently, then you may have other project management issues to contend with in addition to development problems; however, this too can be resolved with AGILE - provided the team understands that with shifting goals the end may never be reached. The constant contact with the customer will provide for a deeper relationship and develop customer loyalty - provided the team leader can manage scope creep.

At a later date we will have to review AGILE and its components in more detail. For today - hopefully you now know what you're getting yourself into and why.

Hope this helps and not hinders, Enjoy!

DOCUMENTATION is for wimps!

Coders code, PM's write Diaries!

Within every major IT department, there really only two job functions: Coders and non-coders. The coders to which I am referring are those people who speak in binary, code in assembler, and haven't seen the sun since their first computer (aka Code Monkey). Then there is everyone else - you know - people. People who speak your language - english or better yet business, people who know technical details as well as the function of a balance sheet and people who can communicate.

WARNING: Graphic Images! This is an actual dramatization... of a coder writing documentation.

Verbose pseudo code

Communication is important. Correction: Communication is VERY important. Whether you are documenting a new application (preferably pre-development), meeting minutes or project status', communication is now at the core of the IT function. No longer is it adequate for coders to just code - they also need business knowledge and communication skills. Sure, a good coder might leave a few comments sprinkled throughout their code libraries, although greatly appreciated - it's not enough.

Now I have to admit - I was a code monkey in training. Yes, yes its true; however I managed to break free. As a junior coder I was stuck in a hobbit hole somewhere coding while the people around me conversed - then I discovered documentation (beam of light from the heavens and choir singing). There was a gleaming piece of hope that I followed out of my hole.

Sure the true IT grit lies with the coders (admins may argue), but you or your team can evolve to be the uber multi-lingual geek. A coder who not only writes code but communicates their intentions to the business and NO we are not writing Diaries and its not girly.  Documentation is like coding - actually think of it as "Verbose pseudo code" and the compiler is known as "Marketing".

Don't be a code monkey - document!

Writing documentation sucks - a lot. However, the benefit is that it communicates your ideas to your team, client and/or bosses. It helps you think through your approach, serves as a road map and simplifies the development process. Ever hear a coder say "Oh I must have overlooked that" in reference to a key issue created by the poorly documented change? Of course you have. With a little communication, the business need could have been outlined for the developer (not coder) and in turn, the approach could have been documented prior to development. The benefit of these steps are:

1. Business articulates their need

2. IT reveals the approach
3. Everyone agrees (scope)
4. Impact of proposed changes (scope creep) can be evaluated against project plan.
5. New team members can get up to speed quickly

In one office, I was replacing the code monkey who decided it was time to leave. I had less than 2 weeks to extract all the knowledge he had because once he left so did the documentation.  The real reason he was leaving? I think he realized he made a mess of the systems and could not remember what any of them did. For the next few months, I spent my time stumbling through the systems and trying to document what they actually did and in the event of a failure - I did this while debugging. Sure we made mistakes - but by the time we were done - the core systems were usable.

Ramble, Ramble - Now The ROI

Good documentation saves time, money, customers and sanity. Coders have a map to follow and what the system does is clear and available - You don't have to step though the code to figure out what it does or wait for the code monkey to return from vacation to point you in the right direction. Customers will benefit from the professionalism and the reduced errors due to forgotten specifications/functionality. Finally, when you stop shooting yourself in the foot, everybody wins!

Hope this helps and not hinders!

-Project: ROI

Links

89 BENEFITS of documentation <-- looks through - not sure there was too much documentation

Benefits of Good documentation

Creppy Scope

Do you know someone with a creepy looking scope?

In case you are unable to identify scope creep, I am including a crude mug shot of what to watch for. Primarily, changes to your calendar; however, that is not to say more work with no change to the calendar is not also scope creep - it is! Actually, lets start by saying that once the objectives and requirements have been identified and agreed to by all relevant parties - any changes to the requirements is scope creep.

  

There is nothing worse than a project with creepy looking scope.

Avoiding the coyote ugly scope creep - Ever agree to something only to want to cut off your arm the next day? Well that’s scope creep coyote ugly! Your job is not to agree to scope creep without consulting the <in booming voice> "Triple Constraint Matrix" <echo echo echo>.

The whosey whatsit?

The Triple constraint matrix contains 3 variables (Time, Scope, Cost) and is your guide to scope creep. No need to worry its incredibly easy to follow - the triangle shows that you cannot change one element without adjusting another. So if you have to make a change just use the formula below"

"With an change in __________, I will maintain ________ and adjust _________!"

So the next time your clients says "We need the deliverable sooner at the same price.", you can respond with:

"With an change in TIME, I will maintain COST and adjust SCOPE!"

With this statement, we can deliver on time, at the price specified, but certain items may not make the cut - in this phase. If the client is adamant that that nothing else change, you'll find that the project just got more difficult to complete on schedule and within budget. If you accept the challenge the client presents, beware that issues in the project will more than likely appear.

Hope this helps and not hinders, Enjoy!