Don’t get me wrong.

Recently I received an email and it went a little something like this:

This article makes a compelling case for Enterprise Architects as active participants in sprints and as close partners to developers: http://martinfowler.com/ieeeSoftware/enterpriseArchitects.pdf

Some of the points I got from the article:

As part of the development team, architects primarily act as customers

In the traditional setup, an “us versus them” attitude often exists between the architecture team and the rest of the development organization

By working together, the architects and developers can begin to appreciate their respective objectives and openly deal with conflicts when they arise.

I didn’t see anything that mentioned joining sprints. This articles speaks to the involvement from all personnel in the system delivery effort. This is a Lean principle “all hands on deck” and it advocates the inclusion of everyone right from the beginning. Enterprise Architects are not called to be involved in the physical implementation of the system but to “act primarily as customers”. This means handing down requirements and helping decided on the priority of the requirements.

I often think that the term “Enterprise Architect” is misunderstood as the “super duper technical lead”. Expecting an “Enterprise Architect” to actively engage in the development cycle and the business cycle is unrealistic. Enterprise Architects would engage at the same level as the Product Owner. Due to the diverse nature of Enterprise Architecture, technology lag can be created and having an EA trying to ramp up during development will cause more annoyance than benefit, especially when certain teams are focused on one technology and other teams are focused on a completely different technology. This is made quiet clear with the statement:

The architecture team must have a much broader perspective, because it must balance a particular application’s needs against those of the entire enterprise portfolio.

“This level of cooperation requires the same kind of resource commitment as that expected from business users.” – this is a key point.

The article is a little frustrating in that it talks about “Enterprise architects” and then uses the generic term “architect”. Each architecture discipline requires a different skill set and level of commitment. The Enterprise Architect is probably the furthest from the development effort in terms of commitment to time spent implementing, with the solution architect and software/application architect progressively getting closer to being actively involved in the development effort.

(This is not a rant on the content of the literature previous provided, just a note regarding the fact that the definitions of architecture roles has been changing over the years with other architecture roles introduced to fill the gaps.) The article is dated 2005 and “what” an enterprise architect is has changed significantly since then. A more up to date article is probably required.

A pretty accurate and slightly less dated article: http://blog.xebia.com/2011/02/28/architects-scrum-4-what-is-the-role-of-the-architect-in-scrum/

And: http://blogs.msdn.com/b/nickmalik/archive/2013/06/11/placing-architecture-properly-into-scrum-processes.aspx

We also need to bear in mind that “Agile” is a concept and “Scrum” is an agile project management discipline. Too often we think because we are using “scrum” we are agile. The only way to measure if you are agile (according to the definition produced by the term’s founders” you subscribe to:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

This applies at all levels of the effort: architecture, analysis, requirements gathering, implementation. The primary driving force behind agile is trust. A group of people does not a team make – even if they are trying to deliver the same thing.

Does Agile need senior management buy in?

Agile has become a major buzz word being thrown around in the meeting and board rooms. It is often assumed that because the development effort has been mandated to follow an Agile methodology the project will take less time. The problem comes when the project is not allowed to follow an Agile methodology. Management gets disturbed when progress is not apparent and starts requesting large amounts of documentation. The development effort grinds to a halt while this documentation is produced. What happens next is a rather nasty mix of Waterfall with Agile expectations. We will call this Wagile.

The problem

For anyone familiar with Agile and the scenario described above, you have probably already identified the problem. One of the 12 principles of Agile software speaks to trust.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

When documentation or proof of progress via paperwork is required, alarm bells should be going off regarding the trust the requester has in the team tasked with producing the work. While I agree that some form of up front thinking is needed before embarking on a development effort, requesting documentation that the up front thinking is being done seems to be a waste of valuable time. We need to ask ourselves why this documentation is being requested.

Why is the documentation being requested?

Going back to the principle of trust we have to first understand the concept of trust. The term is thrown around rather loosely nowadays and holds very little value. A quick “define trust” search on Google gives us the following definition:

“firm belief in the reliability, truth, ability, or strength of someone or something”

This firm belief is not something that comes easily, especially when millions are being poured into the project. Especially in large corporate environments where the stakeholders funding the project are not involved in the day to day operations of the team. Small start-up companies have a distinct advantage in this space because a flat organizational structure means it is easier to include the stakeholders funding the effort. With this reasoning, it is pretty easy to see why the documentation is being requested. The stakeholders funding the project do not see the work being done and the progress being made. This lack of visibility leads to a feeling of distrust that work is not being done yet people are getting paid.

How do we negate this distrust?

The easiest way to fix the problem described above is to increase the visibility on the work being done. There are many different ideas on how to do this but the primary point is that it has to be easily accessible to the relevant stakeholders. Once the stakeholders have complete transparency on the work being undertaken, they tend to understand the problems the team is facing and are far more inclined to introduce means to help mitigate any impediments preventing the development team from succeeding. This is why it is imperative to follow another principle of the Agile manifesto:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

People with a hand in the project need to be easily reachable. They should engage each other regularly. If a question is raised, an attempt to should be made to resolve it immediately via a conversation with the party that might have the answer. If a decision is made it should be communicated to everyone that needs to know about it. This is were things become tricky.

Increasing visibility

Often, as technology professionals, the first thing we want to do to solve a problem is introduce a system. Task tracking, time tracking and the list goes on. Everything has to be logged into a system, carefully recorded for auditing purposes to prevent any recourse if something goes wrong. The underlying thought is one of “if this doesn’t work out, at least I have myself covered”. The problem with introducing these systems off the bat is it violates the Agile manifesto, namely:

“Individuals and interactions over processes and tools”

If any teams is just starting out down the Agile road after being heavily involved in Waterfall development, introducing tools and processes increases the risk of everything being molded into a Wagile process. While the tools say “Agile” the underlying process is very much Waterfall. One thing people find very hard to let go of is the investment they have made in learning things. The one way to get people to let go is to introduce a mechanism that is completely contrary to what they are used to.

Having coached a few teams in Scrum, the initial resistance is generally dropped when people start interacting with the methodology. For some reason, the act of moving a physical sticky note from one column to another leaves the individual with a sense of accomplishment. The side effect of moving the sticky note also leaves a status update that anyone can view without having to request status documents. This visibility increases trust and teams are not weighed down by the burden of evidence proving they are working.

Once the team is more mature and have established a means of organizing themselves, tools can be introduced to replace manual means in use. The reason manual means are better initially is because while you are establishing how your team will work, the process might go through multiple iterations. Software tools have a habit of being very difficult to easily reconfigure once the process has been set up.

Another means of increasing transparency is the demonstration of working software. This speaks to a few processes in the Agile manifesto:

“Working software is the primary measure of progress.”

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

The demonstration of this software on a regular basis shows the relevant stakeholders that software is being built. So as opposed to pumping money into something for month and seeing nothing, people get to interact with software and see additional features being added continually.

How does senior management fit in?

In large corporate environments (the context of this article) senior management is often difficult to get hold of on a regular basis. Often the feeling portrayed to development teams is that they have far more important things to do and keep up to speed with the progress of development.

While it cannot be expected that they will attend daily stand ups, view boards depicting progress or log into software tracking progress, they should attend the demonstrations of the working software or at the very least, have access to the working software. The demonstration would be first prize due to fact that contextual questions can be answered face to face. This will also help establish a stronger feeling of trust in the development team.

In closing, Agile does not work unless the entire organization buys into the effort. It is imperative to have everyone involved from the beginning. It does not work if teams go off and collect requirements then flush those requirements down to development teams and wash their hands. Inevitably development teams will push the requirements back to the requirements team who will have to reschedule time to answer the questions and potentially go through another requirements gathering exercise. By the time the requirements are solidified, the business has changed its requirements and the delivered software no longer meets the immediate requirements the business has.

Business people and developers must work together daily throughout the project.”

All hands on deck!

References

  1. The Agile Manifesto http://www.agilemanifesto.org/
  2. 12 Principles of Agile software http://www.agilemanifesto.org/principles.html
  3. Definition of trust https://www.google.com/search?q=Define+trust