Setting up an agile team room

It's Week 2 of our agile project and thought it would be neat to share an agile team room that we have put together for our current project. There is always a bit of thought that needs to go into making the workspace "effective". The room needs to support a project of ~20 resources by facilitating a daily stand-up of "walking the board", parallel analysis and design sessions of small groups 3 - 6 people and provide instant visibility into key project artifacts. We have decided not to co-locate the developers into this room and instead looking to bring in 1 - 2 desktops with environment access for pairing, spiking and design collaboration sessions. Still waiting for the desktops right now.

Here's a play by play of the room during Week 0:

We just threw everything up against a large wall and we didn't have much artifacts at that time, just a system context, story map, CRC cards, and a high-level value stream (on the right).




 

 

Shortly after, we moved into a dedicated room and we put some effort into thinking about the 5s from lean to help optimize the workspace.

Our full end-to-end Kanban board is operational and running now with an issue escalation board to the far right.

Rapidly growing story map with system metaphor diagrams (state machine, process flow) below it for easy accessibility during analysis and design sessions.

Low-fidelity system context mapping exercise, planning to soft copy this into something more elegant once it stabilizes.

Similar set-up for the CRC card modeling. Again we are sticking to low-fidelity design. Notice the handy bin of cards, stickies and other physical items that are easily accessible during modeling sessions.

Finally, a table with all the current "big upfront requirements documents" provided by the business. Unfortunately, this is a necessary evil as we have yet to transition the business into the agile/lean culture of doing requirements. Notice the difference in "information radiation" between these docs and the rest of our "agile artifacts" around the room.

Overall, looking forward to seeing how this room continues to evolve.

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.