Agile Project Management

Agile is not a trend anymore. Agile has established after 20-25 years of hardwork, learning, sharing and more learning and sharing. Before we wrote the Agile Manifesto we all worked in the domain we favoured and/or published on. For me it was Dynamic Systems Development Systems (DSDM, now known as the Agile Project Management Framework) which was pretty popular in the late ’90-ties and used a lot in banks, governmental organizations and IT-suppliers in the Benelux, the UK, Sweden, Denmark and also expiremented on in Australia, France, India, etc. 
The Manifesto sort of created a center around which we could share and learn with a focus. Where I lived and worked after writing the Manifesto at that time first extreme Programming (XP) started to get attention and some years later after, around 2005 Scrum started its journey more and more. Today Scrum is still dominating the Agile domain and new arrivals have been around now for a couple of years, either big or small.
Today working with one Agile method looks to me as missing the point. Every method has its own community (or more then one) and for me it is very wise to assemble and to take the best of the learning from all the people active in the communities. Like most authors of the Agile Manifesto I visit communities a lot. Of course my focus is on Europe (for travel efficiency reasons, I like to be home every now and then too ;-)) but wherever I go I meet people and sometimes I visit communities outside Europe. This autumn the Middle East and Africa are programmed as well.

Coming back to take the best from the learnings of the communities, of course I do this my self as well (although I don’t do Agile Software Development projects anymore, until today my work has always been full delivery Agile). I recommend my customers on what I think will help them best, giving what I know in their situation when I help them to become more and more Agile. And this process we do of course Agile too.

When I recommend my customers I tend to focus on 5 topics:

Quality of code

This is for me essential. Often people transfer Agile into an excuse not to work properly. Self organizing is often used as the phrase to keep people out and not share information. Instable solutions, lots of issues and unhappy customers consistently follow. Transparancy is a key factor to Agile success. I love to put in place the XP-practices such as test driven development, pair programming (or pair develop when you work outside the domain sofwtare development) and refactoring. Those practices avoid one of the biggest risks we have in every team, knowledge isolation. The practices bring, when applied with the right discipline and quality (I think it was Ron Jeffries who said “it is all common sense but it is uncommon discipline”) good stable products. In our own factory we rely heavily on those practices and because of those practices we are proud to say we have very stable products up to the level where we sometimes have up to 6 months without any incident.

Team dynamics

To get it all done you need to create and facilitate this “self organzing team” most people know from Agile. You have to understand the dynamics of group development and different individual learning styles of course. Once you are into thise concepts, Scrum is really helpful with its daily’s, plan boards, poker sessions, retro’s, etc. to help the team in its’ daily work and short timeboxes to understand where they are as a team and how to continue progress, learning and improvement. 

Visualization

To be honest I don’t know where or when this is originated. I have done this my entire Agile life (since 1994 thanks to Willem Thielsch) with of course a lot of learning, innovation and improvement. I sort of started improvising in my first sessions in 1994 and discovered quickly the benefits of visualization (like I think Allistair Cockburn demonstrates in his graph on the richness of communication). We know the plan board from KanBan, as implemented in Scrum, but there is so much more to visualize. Especially when you consider we recognize the value of registering information but detect the sever risks of documents (working in silo’s vs. end-to-end, freezing information vs. accepting changing requirements as a fact, individual responsabilities vs. team responsabilities or the most horrible one, mixing up different versions of documents ;-))). Using visuals for architecture, datamodels, screenflows and any other use you can think of, as agreed way to document is extremely powerful.

Handling the workload

Especially for teams involved in more than just the development (extra work such as operations, support, etc.) you need to support the team in how to handle the unpredictable. They will have the work they commited to as a team to deliver but also incoming work (tickets, incidents, whatever) which can not be predicted. The KanBan practices with fast lanes and maximizing WIP are proven effective to solve this and I recommend them often. 

Larger projects and connecting teams

And then we have the sheer size of the – to be build product – as something which has an impact on how we approach the development. Weither we like it or not, often we have dates in the future where we have to deliver significantly sized complete solutions. I am talking not just developing and delivering software but delivering initial products of complete solutions including the organizational change, audit trails, trained end user populations, data migrations, infrastructure and marketing & communication. 

How do you do all this and still manage to keep the transparancy? There are 2 important components, to create an efficient and shared starting point for deveopment and after this finding a way to keep all people involved synchronized during development. 

For this purpose I still find my support in a very basic DSDM/AgilePM-practice, the Foundations. In a couple of weeks (1 or 2 sprints if you like) of working full blown Agile, creating a synchronized starting point for groups up to 70 people or more, devided into parallel teams. The Foundations create a way to connect the dots in how to work (a shared Agile language, Management Foundations) and on what to work on (objectives, requirements, the Business Foundations). 

What I especially like in the AgilePM-practices is the easy way for selecting or de-selecting requirements, including the non-functionals. All this with the focus on creating business value while handling new insights. AgilePM has a focus on delivering what the business needs including organizational change, etc. I know some people state there was no full delivery covered when we wrote the Manifesto but I can garantee there was. It was first published in DSDM (in February 1995) which I represented when we wrote the Manifesto. It covers not only how to work but also who to involve. “All stakeholders” is more then just Dev and Ops. 

One of the things I re-use from the Scaling Agile Framework (SAFe) during Foundations, which has a lot of similarities with DSDM, is the big planning session. For me it is a perfect finalization of the Foundations because it is the ideal moment to synchronize all people involved.

After talking all these methods I would like to say, the methods themselves don’t really matter anymore. They will evolve, innovation will take place in the communities. Practical application will be an assemblation of the aspects from the methods to suit you best giving what you know and need at that time. In a few months things can change, they need as well and you can adapt. After all, this is what Agile is all about.