Meeting Unique Challenges for Delivering Faster and Smaller in IT

One of the first principles in lean is delivering faster and in smaller batches of work. Delivering faster means we learn quicker (more information) and releasing in smaller batches helps us get more predictable and minimizes a lot of complexity. More information, more control and less risk. All good things.

However, despite these benefits I often encounter clients that are skeptical whether this is realistic with the real world challenges they have to deal with. The domain my clients (IT) tend to live in are often large enterprise organizations that spend most of their energy maintaining legacy systems or modernizing them to newer platforms. Enabling the business is their purpose. Unlike product vendors that focus on pushing out new products for others to instantiate, IT has to transform and integrate products into solutions that work with their business (people, process, technology). This tends to bring out a set of unique challenges specific to IT that is often not discussed in detail in the agile and lean communities. Some of their typical key challenges when trying to deliver fast and release in smaller batches are:

• Data Dependencies - enterprises tend to deal with large amounts of data (often with strict regulations), need to guarantee integrity and carry data with them as they evolve (data conversion is a big task and cut-over planning is essential)
• Integration Dependencies - systems don't sit in isolation within enteprises and often there is a large sprawl of integration between systems with inflexible interfaces (often point to point with legacy techniques and not documented) resulting in a complex network of dependencies
• Enterprise Governance - running a large enterprise is complex and CIOs often want to instill some sense of order in how things are implemented and governance is one way of doing that which often becomes a significant transactional cost when running through the SDLC process for every small release
• Infrastructure Provisioning - often the infrastructure group is detached from the delivery teams resulting in a silo-effect where the request process for environments is long, inefficient and error-prone (project start-up and iterative scaling is hard in this environment)
• Change Management and Training - fast system releases means the business users need to deal with frequent changes in their business process and this results in the training teams needing to deal with an increased workload and a business culture that needs to integrate changes into their BAU (business as usual)

While these are all tough problems to solve and are largely dependent on context and environment, I think there are some good potential solutions out there. Too often the first response is to give into the challenges above when the answer should be "yes we recognize the real-world is ugly" and "let's figure out how to better manage our dependencies and be more efficient and streamlined in how we work". Reduce dependencies and reduce transactional costs. Based on some of my real-world experiences, readings and thoughts here are some potential solutions I have cobbled together from various sources:

• Domain Driven Design Team Patterns - this is probably one of the most powerful ideas in Eric Evans book that still hasn't penetrated into the general IT vocabulary and is one of the first tools I use when dealing with integration dependencies
• Lean Governance - one way of removing the bottleneck of enterprise governance is to focus on "enablement" and "flow" vs "command and control"/"endorse, review, approve" and "policing", some folks like Scott Ambler have written some articles on this topic but additional effort in this area aligning agility and lean with some of the other more traditional groups (e.g. TOGAF) out there would be interesting
• Platform as a service (PAAS) - one easy way to move infrastructure provisioning along is to move away from providing "boxes" and "wires" to offering end-to-end dev/test/prod application environment stacks to delivery teams using shared environments, some organizations are offering this externally as a business (e.g. Amazon) and internal IT shops should look at how they can bring their own variant of this into their infrastructure groups (my current public sector client is doing this today)
• DevOps - another common problem is the silos between operations and development and there is an active community looking to solve this by pushing the DevOps paradigm (development + operations) and making it work in their environments, some organizations (e.g. Facebook) have really pushed the boundaries here and merged the roles into one with "developers" actually implementing patterns in their code (e.g. Gatekeeper pattern) to help solve release management challenges
• Change Management and Training - there is an increased awareness today that usability experts need to be engaged in the delivery process early on and getting them to work in an agile and lean way is something that is starting to be discussed but good usability can only go so far and there has been little discussion about how to embed change management and training resources in the team and getting them engaged in the iterative release process, new releases without users doesn't deliver much value to the business at the end of the day

Agile Adoption in the Banking Industry

I was organizing my email today (large backlog as usual, need to put in a policy where I purge things after 6 mths) and came across a summary I had from an agile adoption survey a few of my colleagues conducted with several large banks. This is by no means a scientific survey, just one that was conducted with senior leaders from several different banks. Thought it was interesting to share. Here are the key findings:

1) Banks are using agile in tactical ways

2) Their usage is largely limited to applying two practices “iterative development” and “co-located teams”

3) Architecture is not interested

4) Business and development are interested with QA on the fence

5) Compelling reason is reduce time to market

6) Main barrier is cultural, looks like there is a strong culture factor against it

7) Key challenge is estimation, they are unable to apply it within their current budgeting model

8) Key success factors are executive sponsorship with appropriate coaching

This aligns with a general observation that I have noticed as well. The movement is largely developer driven with business wanting to get in but challenged by their budgeting model. Architecture and QA are largely not bought in.

Value Stream Mapping Session Gone Awry

During one of our lean client engagements, we conducted half a dozen value stream mapping sessions with various groups and project teams from the client organization and this session was an interesting exercise. The session involved a large cross-functional team responsible for maintaining a very large-scale system and we wanted to get representatives involved from each stream / discipline (PM, BA, Dev, Test, Training, Architecture, Service Management, Infrastructure) to get the holistic picture. We ended up with a group of ~20 people and one of our facilitators (i.e. Jeff Anderson) decided to facilitate using a decentralized approach and handed out stickies to everyone and asked everyone to come to the wall and map out their specific processes in the value stream. This is what we ended up with:

Needless to say, I am having a "fun" time transcribing this into a visio diagram (we promised the client we would capture the value stream and give it back to them as a deliverable). Next time we have such a large group, I think I will use a different approach (lesson learned).

How-to Conduct a Remote Agile Daily Stand-up

Physical objects tend to help teams perform, communicate and operate more effectively. We've seen this trend with iteration planning boards, kanbans, continuous integration orbs etc. So, we thought how we can make daily stand-ups with a distributed team more effective? Here's our answer.

Architect Police vs Architect Leads

A classic problem I encounter in various IT organizations is the massive divide between Architecture and Project Delivery. Most organizations today have recognized that architecture is important to the organization and as a result have established some form of Enterprise Architecture Governance (Architecture Review Boards, Advisory, etc). This is a good first step, as having a central body that can provide holistic and strategic oversight and advice can help consolidate the maze of systems and designs that has been inherited from past bad behaviours and move organizations towards a rationalized portfolio.

However, in an effort to provide "independence" these governing bodies often suffer from the classic ivory tower syndrome and have evolved themselves into a "policing" role. As a result, project delivery teams looking to deliver cheaper, faster and better for their clients find themselves at odds with Architecture which they look at as a speed bump to their work.

This "architecture policing" anti-pattern tends to produce the following results:

• directing scarce and valuable experienced resources into producing conceptual and logical architectures that provide little value to delivery teams
• emphasizing "policing" over "advising" and "leading" resulting in architects that are out of touch with the client requirements, project context and implementation decisions
• mandating high ceremony checkpoints with heavy documentation and review that slows down project delivery while adding little value to the team and clients
  

Instead of playing the role of police, architects can provide much more value to an organization by decentralizing themselves back into project delivery roles and taking ownership of delivering solutions to clients. During my attendance at the IBM Impact Conference 2010, there was a great success story with a Leading Canadian Bank that delivered an enterprise wide service bus architecture and framework with working code led and owned by their architects. The organization established Framework Architects that were responsible for designing and evolving their ESB framework and assigned responsibility to channel and business facing Solution Architects to extend the framework for their specific client needs.

I am hoping to see more organizations continue to follow the approach of embedding architects in delivery and leading the development of core frameworks and assets for reuse / extension by the organization. Architects leading by "doing" is always a good thing.

Agile Documentation

As a new theme to my blog, each week I will be pulling out one of the LEAN practice cards to talk about and discuss some of the concepts behind it as well as add in any colour commentary I may have based on my own individual project experiences.

The first card I thought would be interesting to look at is a Management Practice titled "Agile Documentation". Documentation is often overemphasized by some project teams or ignored by others depending on whether they subscribe to a waterfall or iterative based process. There is no clear cut answer on exactly "how much" documentation should be done as it is dependent on a variety of scaling factors.

Regardless of which development process your team may subscribe to, if we go back to the "why" behind documentation, I think applying Agile Documentation will help any team minimize documentation waste while also providing the benefits of documentation (yes, documentation is a good thing and even agile teams need to document as going agile is not an excuse to avoid documentation).

The LEAN Agile Documentation card states:



Document...
- When the business asks you to
- For clarity across teams working in different locations
- To establish appropriate business and technical context for the solution
- To define interfaces across systems
- To enable your next effort
- Informally
- To understand
- To communicate

Don't Document...
- To specify
- Because your process says so
- Unproven ideas (prototype it first)
- Without obtaining the structure from your intended audience
- Without considering maintenance and cost of ownership
- Implementation and design details that can be just as easily expressed in the solution itself

There are three main themes I want to pull out from this card that I think are worthwhile to discuss.

1) Document for an audience - Documentation requires time and effort and the business is paying for this just like they are paying for each feature built into the solution. Every project should contain estimates for time/effort (i.e. cost) towards documentation and this is something the business is paying for. If you look at many organizations and their development processes you will notice that there is often a large set of documentation that needs to be completed as part of the project. However, it's worth questioning does the business really need each one of these documents? Does the technology teams building and supporting the solution need these documents? If the team is documenting...

- Because your process says so
- Without obtaining the structure from your intended audience

Then it's likely the team is not documenting for the business. Generally the type of documentation I find invaluable to the business and the technology teams supporting the solution are operations and support manuals (e.g. run books), developer setup and build manuals, end user manuals and the delivery or release plan. This set may need to be expanded depending on the project.

2) Avoid documenting things that will change - Just like code and test cases, documentation is impacted by changes. To avoid paying the "rework" cost, hold off on documenting until a steady state is achieved (document at the last responsible moment) and stay away from implementation and detailed design details that will require frequent changes to the documentation.

3) Document to understand, communicate and establish contracts - It's important to recognize when the scaling factors impact your project and documentation is a great way to mitigate these risks and challenges. When your team is:

- Geographically distributed
- Large and difficult to manage
- Working in a complex business domain

Then documentation helps everyone understand the same language, communicate decisions and changes, and establishes contracts that helps each member understand how their work interacts with everyone else. The type of documentation I find myself often using to help the team navigate through these challenges are the high-level requirements (e.g. use case hierarchy) produced from the initial requirements envisioning sessions, ubiquitous language dictionary and high-level domain model, system context diagrams and bounded contexts, and system interfaces. An extremely effective practice that I often apply to documenting system interfaces or complex business domains is to use "executable requirements". Writing test cases as a form of documentation is a great way to precisely capture the details while also validating for correctness.

I have found these three themes combined with the bullet point checklists in the Agile Documentation practice card to be incredibly helpful in deciding what and when to document.

DSLs and the new Analyst tester

Domain specific languages (DSLs) are quickly gaining momentum and there is definite interest in how the industry can adopt DSLs in the requirements world. I think DSLs can act as a bridge to help cross the divide between an "analyst" and a "tester". While, I don't think the industry is ready to adopt DSL's in the large, there are several easy wins here that I think can be easily gained by the industry if we start small.

1) Get the analysts involved with delivery -it's time to accept that the old fashioned approach of making up requirements and throwing it over the wall has failed. Instead, embed the analysts with the developers and testers. Make them work with the team, jointly capturing requirements together and creating tests that validate that the system.

2) Executable Requirements - start writing automated acceptance tests. These acceptance tests are described one level up from "code" and can start looking like a natural language. Wikis like FitNesse (http://fitnesse.org/) are an excellent example

3) Behaviour Driven Development - the next step up from executable requirements is to embrace a DSL-like mindset to drive the design, development and testing. There are emerging frameworks that allow a tester or developer to write test cases in code that mirror the language of the business. See, http://behaviour-driven.org/

If we can get these three practices right, then I think we are half way up the hill towards understanding and using DSLs. Already there are many organizations and teams that are pushing the frontier with these practices. As these practices get adopted, the "analyst" will evolve into a capital A - "Analyst", lower case t - "tester" and the two roles will be merged into one.