Why co-located team rooms are important

One of the most valuable aspects of co-locating a team in a common area is that it eliminates a lot of the "us vs them" mentality that tends to happen when team members are working in different locations. I have observed that it is a fairly natural occurrence in teams that are distributed to be less collaborative and helpful to each other if they are separated by distance.

For example, here's an interesting email conversation trail from a previous project between two distributed teams (in the same building but different floors and opposite ends of the building):

Email 1 from Debugging Developer:

Hi Developer B,

I was wondering if processing transaction A is supposed to work for ActionTest. I’m using the following data with an error of “failed to execute called process”, can you advise, thanks.

Data used:

Some complex XML message      

     

Response email from Developer A:

You sent a transaction per below.  The changes were not deployed on the tActionTest.  I will have to rebuild that deployable.  (It was deployed for the end-to-end process, not the test webservice.)

I can't find your request in the logs to check the error.

Thanks,

Developer A

Email 2 from Debugging Developer:

Ok so I guess it shouldn’t work until its been rebuilt right?

Response email  from Developer A:

Yes, I forgot about deploying the test service because I was focusing on the integration model. 

Developer X just deployed the most recent ProcessingComponent changes on the test service, and this included my code updates, so the service should work now. 

ProcessTransactionService fails this sample request as per below:

  

  < Failed OrderDetail(s) : 9084694735  ErrServiceQueryFail

   updateSubscriber_ERROR-1553

and more complex XML/>

Thanks,

Developer A

Email 3 from Debugging Developer:

Great, yeah I see that error now, middleware integration admin logs for ActionTest still times out. I’m not sure why the error occurs, is there any way that I can dig deeper? 

Response email from Developer A:

Look at the ProcessTransactionService.

Email 4 from Debugging Developer:

Any idea what “Failed Tranasaction(s) : 1234567 (error=-65608)” means? I understand that transactions with FDR of 232 and IBC of 456 must be used, so I specified the following request:

Some complex XML...

Response email from Developer A:

Did you intend to address this to me?  I don't know this.  AquaLogicBus is calling the ProcessTransactionService (java).  This error is returned from the ProcessTransactionService.

Thanks,

Developer A

Email 5 from Debugging Developer:

Yeah, I just thought you might know, Developer B might have a better idea.

Developer B, I’m sending the request below to AquaLogicBus and get the error: “Failed Tranasaction(s) : 1234567 (error=-65608)”, tn I used is:  ,

What rules are there for Transaction A?

Thanks.

Response email from Developer B:

But the error is self descriptive...the transaction is not unqiue i.e. processed...you cannot process the transaction twice/more in ProcessTransactionService.

Email 6 from Debugging Developer:

I have yet to trained myself to understand (error=-65608)

I’ll try more numbers even though numbers such as 1234567 and more also do not work for Transaction A, these numbers have not been processed since they were verified by GetStatus of the ProcessTransactionService returning ErrGetStatus.

After a bit more back and forth, finally the Debugging Developer discovered the root cause of the problem. In total, this took 6 hours and ~10 emails. Think this is a good example of the communication effectiveness Alistair Cockburn talks about:

Kanban - Add colour to your work to help the team focus

One of the aspects I find valuable with Kanban, is the work visualization. However, sometimes I find that the work is so chaotic/iterative and collaborative in some portions of the process that the standard columns and rows in the kanban board don't provide enough flexibility. You'll see this when you have one work item that requires separate but related work from multiple team members due to their specialization.

 In these situations, I avoid trying to fit the highly iterative work into columns and rows, and collapse them together into a single step on the board. The problem I run into when I do that, is it becomes hard for the team to figure out who is working on what and what work remains to be done on the work item.

To solve this problem, I apply colour to the work using coloured stickies that I "tag" on work items to denote what's be done on each particular work item.

In this example, the team pulls a work item (user story) into the "Create FitNesse Template and Automate" column of the board. To move an item through this part of the delivery process, requires the team to define detailed acceptance criteria in the language of the domain model, get it into a FitNesse page, and then automate the tests. This requires at least three specialized skillsets, a business analyst who understands the requirements that can help define the acceptance criteria, a developer that can verify that the acceptance criteria can be automated and develop the automation code if needed (fixtures etc.) and an architect/product owner that can review the acceptance criteria. Also, the work is not necessarily sequential and may be done in parallel or require multiple iterations.

To help visualize the work for the team, we applied coloured stickies that are tagged to each work item once something has been completed on it. For example, if the FitNesse template is done and data is defined than we tag it with a red sticky. If automation is completed / not required than it is tagged with a blue sticky and upon review from the architect/product owner we tag it as yellow.

A neat result of this process, is that each team member can immediately tell what item they should be working on. The business analyst just needs to look for work items that are missing red tags, which is a signal for them work. Similarly, blue for developers and yellow for the architects/product owners. 

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.