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.

Technological changes and cultural changes

In most of my change cases you can divide the project change target into two entities: Technical changes and cultural changes. It is impossible to say which one is the more challenging one as it very much relates to the challenge on hand AND the project's capability to perform i.e. what kind of skills do you have onboard.

Taking a bit general approach I could say that technological changes (systems and tools) are easier one. People need to understand the tools and related processes and you just put the focus and effort on effective training and support.

Cultural changes are more difficult to handle. First of all, in a global company you need to work on the company culture and the anthropological culture. Both can have influence on management styles, attitudes, standards etc. and they are hard to manage.  I guess that the basic tools are once again the same that can be used everywhere - user participation, communication, leadership and commitment from the top.

From personal experience I could pick up two things. First of all - get familiar with the culture which should be changed. Talk with the people, meet face-to-face, have a coffee with them.  Understanding the "unknown" helps you with your tasks. On the other hand pay attention to the change champions. Find the right people who are willing to change, how have organizational position and more preferably are mind setters in the old organization and with the CM tools convince them to do the work for you.

Remember to check that how the organization dynamics work, what role does the hierarchy play. Make sure that you understand how decisions are made - I mean really DONE.

Some reasons why people are likely to persist with their existing tools and mindsets


There are lots of material stating that human side of the change is overlooked in ICT projects - or maybe I am just reading those studies ;-)  Clegg & Walsh (2004) suggest that in many cases too little attention is paid to the social side of change. They also list some reasons why people are likely to persist
with their existing tools and mindsets:

• There are no clear, unambiguous reasons to change
• They do not trust the people telling them to change
• They are under pressure and they choose to trust in the familiar
• Replacement tools are not proven (or worse, do not exist)
• Dropping existing tools seems and feels like a failure
• Everyone else is using the same tools
• The tools are part of the group‟s professional identity (“our tools are us”)
• Use of the tools conveys power and legitimacy to their users
• The tools serve and further the interests of their users

Reflecting these topics against my own experiences

They do not trust the people telling them the change. Is very true and also a difficult topic to handle. In case you work  as a consultant and organizations, teams, projects, companies come and go you are not the person to have the trust at the beginning - you may work to gain that trust, but this is more like a stakeholder management and comms issue. You need to involve the right stakeholders, get them to "Committed" state and let them to speak on your behalf. These key persons can be from management as well as from peer group (opinion leaders).

It requires a lot of work to identify the right persons and also interpersonal skill from yourself to work out the topic with them.


Replacement tools are not proven (or worse, do not exist)
As a pro project leader you need to understand what do you have in your hands. When the tools are not proven it will create a certain risk to the project. You need to manage the risk according to risk management methods. What comes to the change management side you have  a dilemma related to the risk - if the tools are not proven you may take (case-by-case) the risk and sell the change not directly telling the target user group the possible flaws of the tools. If things go right you are clear, but this is kind of one shot case. It will be lot harder to try convincing people again once they have noticed that you are not telling the whole truth see They do not trust the people telling them to change. You may also take the honest approach and communicate where the development team is with the replacement tool, react to any feedback and try to get the things on track.

All in all this is a case where I would look into mirror and think - Do I believe into this myself? If the mirror response is No - then you may need to say to your boss that I am not the right person to lead this change.

Everyone else is using the same tools is a tough challenge. I have worked in several cases where the goal is to improve something by replacing the tool or cases where you are forced to change the tool e.g. for technical reasons. I have not found a silver bullet to solve this. Lots of cases the new tool is good for the company on average, but it is a step back for many. How to tackle that. I guess you need to dig into the "what's in it for me". This is also a typical case where you need to plan and communicate the big picture how to move will go through the whole user domain.


The tools are part of the group‟s professional identity (“our tools are us”)
...OK, I give up. How to tell the guys who maybe have developed the tools and have been using them for 10 years and the support guys sit next to the team in the same floor. Let's not forget the CM basics, but I guess in this case it would be good to talk to management, show some carrot (bonus).

Three key factors for successful project

An ICT project must have three key factors in place in order to have chances for success. The factors are: communication, a competent project manager with project experience and knowledge about the organization‟s
core business, and top management support. Change management is an important part of the general project  management but it is not enough alone if the project manager is otherwise not competent enough or other key factors for a successful project are not in place.

Source:  Master's thesis: Change management as a part of successful ICT project management
Antti Pasanen, 2009
Department of Marketing and Management
HELSINGIN KAUPPAKORKEAKOULU

This theses supports my personal experience in project management:
Communication
A competent project manager with project experience and knowledge about the organization‟s core business
Top management support
Communication - today's work is plenty of communication and I am not talking about the amount of communication but the quality of the communication - right message to right people right time and feedback loop that the message got through in a right way.

A competent project manager - what can I say in same areas you can still see thinking that project management is something anybody can do. It is mainly a mandatory thing that must be  in place and hopefully he/she does not cause lots of extra cost or hassle. However, I think just like in any other area experience is something that will ease things. Also project management must be treated as an own competence and developed systematically to reach higher standards.

Top management support - In case you don't have a killer application to roll-out you will face challenges when trying to change something. It is crucial to have management to deliver clear message supporting your activities at the same time as you need to work bottom up to clarify what's in it for me. And when the shouting gets louder it is good that you have managed your top stakeholders well and ensured their commitment. This may carry you over the hard times in the project even though pure top management support alone does not guarantee anything - at least my experience in most of the corporate cultures I have worked.

This is supported nicely by this article by sixdisciplines.com: http://www.sixdisciplines.com/_blog/The_Six_Disciplines_Blog/post/Change_Is_Inevitable_Failure_Is_Optional/

Selecting the right tool


A good starting point for the tool discussion is that the tool is "only a tool". You need to have competent people to use the tool(s). Another thing to remember in this tool decision is that when talking about agile, scrum, kanban or even pure waterfall these all tend to cover just the core layers of the work. There is a lot more in making a project successful. I mainly touch that area in the Change management topic.

How do you know which tools to apply. Well, I don't have an exact matrix how the tool evaluation is done, but
Clear target vs unclear target
Clear target and scope makes it easier to pick waterfall approach... but keeping in mind the good agile practices - keeping customer closely involved, regular short improvement cycle and working on the plan details as you move on.

• Experience vs. inexperience
• Have we done this before?
• Small change vs. big change
• Realistic schedule vs. unrealistic schedule

In a real work there are situation that you just have to live with the unrealistic schedules
I would pick up an iterative approach to reduce the risk not delivering anything