Monthly Archives: April 2015

Avoiding a Rough Start

Often organizations will start an Agile journey by sending their project managers and/or development leads to Scrum Training. Upon their return they are expected to implement Scrum with their new training and knowledge. Sometimes this is driven by one of the groups sent to the training, but often it is an edict sent down from upper management. In either case this is setting the organization up for a rough transition to Agile.

Cracked Asphalt Road

Naypong – FreeDigitalPhotos.net

In general smooth agile transitions require more than an internal employee bringing info in from a two-day course. Support is needed from every level of the organization to make things work. Involvement is needed from everyone who will be working on the project teams. Different roles need different training to succeed with their new process.

Sending someone to training is a good start to the transition. A better start would be to send an entire team. This shouldn’t be a team of project managers, but the pilot team making the initial switch to the agile method of choice. This prepares the pilot team for success.

When the team returns they should meet with their management support. Two important things happen here. On one side management can communicate the hopes they had in starting this process. The other side is that the team can communicate what they expect to see happen in the first six months. This doesn’t have to be a confrontational time. Management saw some possible value in this to begin with or they wouldn’t have sent the team off. Bringing in an outside consultant can help keep everyone on track. The team is new to the whole thing, but should know enough from training to set some initial expectations for management. Chances are the team will not be able to transform as radically as management initially thought. On the flip side they should be able to promise greater transparency into what is happening during the transition than management expected.

With an entire team trained and proper expectations set between the team and management the actual transition can start. In a perfect world the team is working on a project that requires nothing from other teams which may impact the new processes they are putting in place. In reality they will likely be interfacing with teams that are not agile and not working to get there. This is where the team all being trained in agile values and principles can be more valuable than the specific method training they have received. Most of the current popular agile methodologies do not deal much with interfacing outside of the team. They tend to assume the team itself will be doing everything from start to finish with no reliance on the outside.

Even with these pieces in place it’s not guaranteed that the transition will be smooth. In fact, real-world evidence is showing that the transitions are almost always rough. By getting everyone trained, on-board, and supported that roughness can be smoothed out. Bringing in outside help is another way to help smooth out the rough spots that are tough to see from within.

Agile During Maintenance

When a team builds a house the project has a very defined end. Once built the original team no longer deals with the house instead handing maintenance and support over to the user. Software development is not like that. Once the initial release is done the original team generally does deal with maintenance and support. When the last release is done they generally still deal with maintenance and support.

Hand Repair And Maintenance Cylinder Diesel Engine Of Light Pick Stock Photo

khunaspix – freedigitalphotos.net

This can be tough for some people tasked with managing agile software projects to reconcile. Projects are supposed to be temporary and have a defined end. Once a project is done it’s time to move on to the next one.

A good way to get around this mindset is to change the delivery. Don’t think about the software as a product to develop and deliver. Think about the software as a value delivery system. Your team is not creating this single product which will then be passed off and forgotten. Your team is creating value for the user. As long as there is more value in enhancing or fixing the software then there is in doing something else for that user then your team should focus on the software. That brings us to how we deliver more value on a product that is out the door. My answer, admittedly biased, is with an Agile mindset. Continue reading