Agile in public web development

Agile is no longer just a buzz word, but you can see great benefits in different context. I came across a blog about agile web development in public sector. The agile approach was very impressive to me. Person oriented, open tendering with a trial sprint with multiple teams. Something concrete to be utilized from that exercise are the template that they used. They give you a good idea of the approach and the "spirit" of the whole case. The English templates can be found in sitra.fi - look for "Dokumenttipohjat ovat englanninkielisiä"

The follow-up of the case can be read in Vierityspalkki.

There is also another interesting blog - unfortunately just for the Finnish speaking audience - Sisältöä tuottamassa blog

How far have we got in 22 years

Started in a new job lately.  We are working on a large program, which is marketed as a "renewal of e-services".  When diving into the subject I have realized that developing a project model and implemting project culture actually starts from strategic planning and educating what does "thinking strategically" actually means for us and for an individual. We'll that's an another story and most likely I will get back to that.

The organization has been a forerunner utilizing IT in its own field. I got hold on to a project report from 1999 and I read about those revolutionary ideas at that time.  The thing that caught my eye was the lessons learnt part - here are just the highlights:

• Installation
• Unharmonized desktop environment (IBM and Mac; 5 1/4 and 3.5 floppy disk drives; different monitors) caused severe problems
• Programs shall be so simple that installation can be done with a Install comman. In addition we need better instructions.
• Applications (can't name them here...)
• Solution is very IT oriented with complicated protocols. The solution has been made compliant with the lowest level hardware, which scopes out some more advanced functionalities like the use of mouse.
• Suppliers
• Support from the primary suppliers has been poor. In the future supplier negotiations we will focus on that.

So, does this sound familiar to anyone? What have we learnt in 22 years? Maybe we are doing better what comes to the desk and laptops, but the range of devices has grown a lot and Bring Your Own Device is there already. We still face those incompatibility topics frequently, but of course in this area things in general have proceeded a lot and e.g. different management systems help with that "Install command"

I still tend to see and hear those IT oriented solution comments. There has been a lot of progress in the area how the user needs are taken into account, but amazingly some suppliers still provide solutions which do not really fit to the purpose.

Suppliers - oh dear, I have worked with excellent people and I have leart a lot working with excellent people, but
a) there are suppliers who have not understood the customer oriented approach
b) organizations need to understand that purchasing is a difficult area and requires skilled people and own expertiese as well

In the market - suppliers want to sell, organizations have need to solve their challenges with solutions, but a lots of education needs to be done to constantly succeed in that area.

Need for PMO

A nice article about PMO in Projectmanager.com.

For the past years PMO has been kind of "de facto" in the working environment. Now I'm facing a situation where I need to think What's in it for me.

• Create and implement consistent systems and processes
• An objective source of truth
• Introduces economies of scale

 Let's see. Having a background in a large international company I truly believe in consistent systems and processes. If you don't "speak the same language" things tend to get difficult. Consistent framework for running projects supports the project work. With the framework I mean simply a defined and commonly committed way of running projects. This may include

• Common methodology which for me stands for the thinking part of the work - we look the work and issues from different angles, we process the data in a similar way.  To put it short "We have thought about it how to make the project happen".  To support the methodology you may need some defined deliverables: Project business case template, project plan template, change management & communication template etc. These will help to implement the common methodology, but just filling in the templates withouth thinking (and sharing those thoughts) the added value of having templates is close to zero. Processes once again play a part in this and yes - it is good to have at least some basics in place.
• Summary: Consistent systems and processes are good but just like in any other case you need to find the right tool for the right job and implement things that are needed - nothing else.
• An objective source of truth is a more difficult topic. For me personally, it is important to have facts for decision making so this supports my need. The but comes from fact that how to ensure with feasible control level that what we see is really the truth. Does it come from the consistent way of working and the processes - everybody analyzes and treates the risks in the same way - dispite their personal risk taking capability?
• Summary: There is need for having visibility to "truth". Is that reached by focusing and putting effort to common practises and processes or how.  So yes, I think idea is a plus for establishing PMO.
• Economies of scale: If this refers to (just like in the article) more efficient usage of available resources then definately yes - PMO is needed.
• Summary: I see this kind of another side of the coin - introducing common practises, streamlining the common effort and removing waste is a good thing.

Project is like an Autobahn

You may create several ideas of the metaphor, but this article confirms my thoughs about the project team workload. In order to perform on high level you need find the optimal capacity of the "Autobahn". 

Feeding in too few tasks for the team is not efficient use of resources, but feeding in too many does not just slow down some things, but finally creates a "Stau" and the whole road is blocked.

http://www.linkedin.com/news?actionBar=&articleID=5585681452680359957&ids=e3gVdjgUcjsUdzAMczcUd3ARdiMVd3sTc3cQc3sTe3kNcPwQejkRb3sTc38Pd3kUdjgTe34Ud3cVdjkIcPoVdPAVc38Vd3oUdzgVczARdiMTdjAVdjcMe3oOdjgNe3oRe3kR&aag=true&freq=weekly&trk=eml-tod2-b-sum-0&ut=1EEk7uHmivllc1

I don't think this is rocked science to discover this as all of us have experienced nowadays, but I just wonder why so little attention is paid to this in large organizations. I'll try to figure that out soon ;-)

Can we develop 'resilience'

What is resilience (From Change first white paper "How to help people and organisations be more adaptable to change")

Resilience is the ability to ‘bounce back’ from a difficult or adverse situation. It’s the quality that enables one person to respond well and thrive during the change process, while a colleague with apparently similar skills and experience
struggles to cope. Resilience helps people regain control much more quickly during times of change. It helps them maintain higher performance levels and improves their overall sense of wellbeing. Resilience also helps people make sense of change more quickly, so they understand the impact on them and other people. At the same time, resilience helps people deal with multiple

The seven characteristics of resilient people

Optimistic: resilient people believe that change will have a positive outcome: they are able to analyse even an apparently dire situation in a way that gives them hope for the future.

Self assured: resilient people have a strong but realistic belief in their own capabilities. As a result they tend to control change, rather than the change controlling them.

Focused: resilient people have the focus needed to be able to prioritise activities effectively. They can pursue goals successfully, even in the face of adversity.

Open to ideas: resilient people have an open mind to different tactics and strategies. They tend to be good at generating alternative approaches and solutions to match the changing situation.

Seek support: resilient people actively seek the support of others during times of change. They look for opportunities to involve the skills and experience of other people as well as their own.

Structured: resilient people are able to analyse the situation and create an effective plan to implement change – with enough flexibility built in to cope with the shifting situation.

Proactive: resilient people are prepared to step out into the ‘unknown’, and take the action necessary to
make change happen.

Lean in project management

In general we can map the following kind attributes to lean

• Eliminate waste
• Optimize the whole
• Learn constantly
• Build quality in
• Project attributes could typically be seen 
• Complete on time
• Complete on budget
• Complete requirements

There is a clear distinction between these two. Lean is more about improvement and focus on essential only as project is about results. That makes this topic interesting - how can these complement each other.

Project management is a process to me. When looking into the lean i started to think this from Value Stream point of view.  Work packages as values stream - weak links in the stream can review the wasteful practises.

This leads to role of project manager so that instead of managing activities the project leader in lean focuses on reviewing the way that work package passes between team members.

Couple of other central topics which should/could be emphasized. The last planner concept. The person who is doing the planned work in the project - make sure he/she is involved in the planning identifying the work, talking with relevant stakeholders and has adequate powers to do the work. Continuous improvement. Pay attention to learning within the project AND keep the scoping under control.

Right tool for the job - what about the architecture

How does the architecture relate to 'project management' discussion. Well, part of the tool selection you need to identify and understand the task at hand - what are the key areas. Why discussing agile architecture here? Because I'd like to understand how a typical heavy upfront activity could be managed in lean & agile way as I am pretty convinced of the benefits of those compared to waterfall.

First of all you can use 'architectural significance' as one priorization criteria, which would put those requirements on the top of the backlog.

Another topics is the right team, meaning that in case you have an identified architectural challenge on your hands the team must be able to cope with 'agile architecture' - ok, this is nothing different from any project/development activity the right people do make the difference in any case.


Quote from Nick Malik at http://blogs.msdn.com/b/nickmalik/archive/2009/04/27/why-agile-development-requires-agile-architecture.aspx

Agile architecture is the act of producing enough architecture to meet the needs of the project, and nothing more, and producing it in a timely fashion, with a minimum of effort.  Agile architecture RARELY produces a detailed class model in advance.

Agile architecture often produces a high-level component model and context model to establish the existence of components, their names, and perhaps even the division of responsibilities in the dev team itself.  (think: Scrum of Scrums).  Agile Architecture nearly never produces diagrams of technical things, like the structure of a message.  Dev tools do that, from the code itself.

Agile architects will produce models using a dev environment tool, like Visual Studio or Sparx Enterprise Architect, not a diagramming tool like Visio that cannot easily be connected with the code.

Agile architects will use diagrams to communicate between people and to express artifacts into code where developers have real freedom to make the magic happen.