One of the biggest challenges of Agile development is introducing its ideas and techniques beyond the project team using them. Project teams tpically see direct, and often immediate, benefits of using agile techniques but for those outside of the project it takes the right leadership and direction to enable agile adoption across the enterprise.
There is really no limit to the number of ways to create and customize an System Development LifeCycle and to some degree every organization and, to some degree, every project needs its own flavor of an SDLC. However, every SDLC should address the following ABCs:
One of the biggest challenges facing agile development techniques is how to scale them to enterprise and global level initiatives that often have distributed teams, long delivery cycles, complex integrations and massive testing and training needs. While this can be challenging there are some approaches that can effectively scale agile techniques across the enterprise.
Agile development techniques emphasize a powerful value system that increase productivity and effectiveness of teams, however, they become even more powerful when blended with the full project lifecycle methodology of the Unified Process.
Agile software development has existed in some form for almost ten years and while it's awareness and benefits are gaining greater market acceptance it's also becoming clear that Agile itself does not provide any better answers that the ideas that had proceeded it. In fact, the time has come to start thinking of Post-Agilism and the next wave of ideas and approaches that will prepare and support software development into the future.
I recently updated a template on my website that I frequently use when either leading iterative development projects or coaching project managers on effective iterative development techniques called the Iteration RouteMap. The word 'routemap' comes from a South African colleague who used the 'king's english' and insisted that the term routemap was more appropriate than roadmap, the name's stuck ever since!
As far as templates go this one is really quite lightweight, however, there are several key concepts that are important when managing projects in general and iterative projects in particular. The first is using a mechanism to determine how to size effort. I typically look at this from the perspective of size and complexity (which is usually a good indication of risk). Large and complex work items should be started early in the project lifecycle. I also estimate using Perfect Engineering Days (PEDs), this illustrates how long something should take without interuptions, well defined requirements and all of the other components that can impact how long it actually takes. A Load Factor is then used to convert PEDs into a realistic estimate. The Load Factor reflects the productivity of the project and is typically between '2' and '5'. A '5' reflects a programming language that is either new to the development team or difficult to work with (such as Visual Basic 4/5 within an object oriented development environment). 2 is usually only achieved when the development team has been working on a project for an extended period of time, usually near the latter iterations of the project (when development complexity should be lower). It should be noted that as you actually get some iterations completed you can start substituting the Velocity of your development for the Load Factor.
The final item is to recognize that there are different Types of functionality/value that will be completed during an iteration. The logical work items are user stories that represent tangible units of business value that stakeholders can identify and provide feedback on. However, often these stories need to be supported by 'Infrastructure' stories which ensure a well designed system which can support its non-functional requirements. In addition, the User Interface (UI) necessary for the story can also be decoupled from the story iteself and is often represented as a separate work item.
Hopefully this template will be useful to both those just starting their agile/iterative development initiatives as well as those who have been doing this type of rowkr for awhile. As usual, please feel free to email me with comments.
One of things that I personally think is important is ensuring a safe and productive workplace for people in order to maximize their potential. Part of this comes from ensuring a safe work environment and instituting a culture of tolerance and respect, however, another dimension that I think is also important is ensuring that the workplace is also 'fun'. If you can have fun in your workplace my logical extension is that you must feel safe since its hard to have fun when you're feeling threatened or worried. When I was the VP of Delivery Services at Valtech I ensured that each one of our Development Centers had some kind of 'activity center', Wii's and Guitar Hero, Ping Pong tables and electronic dartboards were all available for tournaments and just casual play. We even had an official World of Warcraft guild for employees and spouses (and there were a lot of spouses!). When I was at BMC one of the events I organized for my staff was a rather remarkable scavenger hunt/trivia pursuit/cranium game that was provisioned by a company called The Go Game. It was probably the best team building event that I've ever been involved in and the company was creative enough to customize the game so that our India team could participate as well. Of course, I come by this honestly having spent my early years running a small company that provided Doom network gaming tournaments.
By adding some 'fun' to the workplace it's opened up new communication channels amongst staff and it's allowed people to connect in ways beyond their work commitments. It's a tricky area of course, one person's 'fun' is not always anothers. When I took over at Valtech the only organizational fun was playing poker, however, not everyone enjoyed playing and felt excluded and even resentful that this was the only way to interact with their colleagues outside of work.
However, it seems that you can take the whole of idea of fun in the workplace to a whole new level. I read an interesting article in the Utne Reader about the "infantilization of corporate America" which describes companies pushing the boundaries of this idea of fun to the point that employees feel like children in school. Clearly there are some 'dos and don'ts' when pursuing these ideas!
Recently I've been involved in some discussions on effective tools for teams collaborating and communicating. The questions revolved around the use of Twitter as an effective tool for collaboration. One of the great premises of the Web 2.0 paradigm is that it introduces a more interactive model for communicating sharing information. Nowhere could this be better leveraged than in teams particularly those that are geographically dispersed. Twitter is an interesting product of the Web 2.0 paradigm as it provides short (140 character) comments on what a person is doing.
Initially, I was skeptical about a social-networking tool like this as it emphasized activities not outcomes. However, upon reflection and reading an interesting article from on my old alumni-BMC blog, I now think this would be a very powerful tool particularly for geographically dispersed teams. Although Twitter emphasizes activities, its these activities that connect people in a community and a software development team represents a focused community. Having a tool that allows team members to understand the activities that others are engaged in provides visibility that can only be accomplished when working in the same general area. In larger companies and in globally distributed projects it's not practical/possible to have teams working together. Twitter and some of the other micro-blogging services like Pownce (which allows you to blast out links to events and even files... which would be useful when a document had been updated) fill a void that other tools like Wikis (Atlassian Confluence), Version Control solutions (Subversion), IM solutions (Jabber), Communication tools (Skype) and Application Lifecycle products (Rally) don't address. At some point all of this seems likely to converge but until then it will be necessary to stitch together these solutions to really ensure effective collaboration of your teams.
If you're using any of these Web 2.0 tools in your environment I'd be interested in hearing about their benefits and what effective practices you've discovered.
I've been involved in using, editing and creating IT methodologies in one way or another for more than 15 years. In my early experiences I even went through the process of creating my own IT Enterprise Architecture framework complete with its own graphical navigation system and a lightweight content management system (I created it to point to documents stored in the file directory system we were using which I believe was Novell based). I keep a reference on my website primarily out of nostalgia but also because early on I saw the importance of aligning business goals with IT strategy and architecture.
My knowledge of process, methodologies and value chains has increased substantially since those days but I'm still surprised at the lack of consistency and even awareness of these topics across the IT industry. It's no wonder most companies struggle with managing their IT functions let alone positioning them for competitive advantage. However, there are an increasing number of robust methodologies and processes available that take the ideas and concepts I mentioned above and can help an organization rapidly mature its IT function with a standardized but custom set of processes.
Recently I've been spending time with a web based, hosted methodology authoring tool from Osellus which is very interesting. It's methodology agnostic (so you don't contend with whether you should start with RUP or Microsoft Solution Framework or other base methodologies) and you can mix and match with a straightforward user interface. It's a hosted solution which means you pay a monthly subscription fee which entitles you to updates and support of the solution. The product comes with a number of base processes and you can add your own libraries or import others such as RUP. It's a very interesting solution and takes a very different approach from Rational Method Composer which is a thick client and starts with the Classic RUP as framework. Ossellus still has a few weak points such as lack of a 'Discipline' package for related roles but its price is quite competitive and relatively low risk for anyone interested in exploring some alternative product solutions.
Of course the big splash in the IT methodology pond has been the effort behind the Eclipse Process Framework (EPF). Initiated through a donation from IBM the EPF aims 'aims at producing a customizable software process enginering framework, with exemplary process content and tools, supporting a broad variety of project types and development styles". I think one of the most interesting outputs from the EPF is OpenUP, a lean version of the Unified Process emphasizing agile philosophies and collaborative development techniques. Implementing an EPF based framework has the benefit of being free but provides a metamodel that has benefited from literally hundreds of thousands of development effort.
Recently I was coaching some people on dealing with organizational changes, as part of the discussion I shared an old management joke that has so much truth threaded through it that at times it doesn't really feel like a joke!
A new manager comes into his office and sits down in his chair. As he settles himself into his new surroundings he opens one of the desk drawers and discovers three envelopes numbered 1, 2 and 3, a small note is attached to them:
"Good luck, in your new job, although I can't meet you directly I understand the challenges you'll face and hope that these 3 envelopes will help you manage through any major problems you run into."
- signed the previous manager.
The new manager doesn't think much about this until a few months later when he is facing considerable pressure to turn things around and show improvements to his superiors. He reaches into the drawer and decides to open the first envelope. Inside is a note that says "Blame Your Predecessor!". Of course, he exclaims and then proceeds to explain why none of the problems are his fault and that they all stem from the previous management.
Things settle down for the next six months until once again he starts feeling increasing heat to show improvements and results. He opens the second envelope and this one says "Reorganize!". Of course, he exclaims and proceeds to create a new org chart changing roles, responsibilities and shifting people.
Once again things settle down for a few months but soon the political pressures mount and the manager has run out of ideas on what to improve or change. He reaches into the desk drawer and pulls out the third and final envelope. He opens it up and reads the next note..... "Prepare three envelopes and leave them in the drawer"...