My last delivery gig was a great reminder about keeping the principles and values of the Agile Manifesto in mind. It was unlike any agile method that you would probably recognise.
We were building a prototype system to demonstrate the capabilities of a technical standard and the data that it contained. Our main stakeholders, both relatively non-technical knew the type of audience the prototype was intended to influence and making a technical standard come to life with an interactive prototype was our remit. We had free reign of how we worked, the technology we used but our approach consistently remained true to the agile set of values and principles – focused on value through the demonstration of working software in a collaborative and adaptive manner.
I think about how we worked at the end of the project, and it looked nothing like how we worked at the start of the project.
Communication was key
Our small team was highly distributed – our two stakeholders located in one part of Switzerland, two of our team members (mostly working) in Germany, one of our team members moving between London, Germany and the client and myself where, during one week was in London, Manchester and then Germany. We knew communication was going to be tough. Our first step was ensuring we kicked the work as a team together in the same place. We spent the first week working with a large variety of industry stakeholders, understanding their concerns, the issues the new standard was going to address, and trying to get into the heads of our own stakeholders about what they were trying to do. This time turned out to be essential in guiding our future work and helped us connect the “what” to the “why”.
With our high level of distribution, we knew that we would need to do multiple channels of communication. We started off with daily stand-ups using video conferencing software with our stakeholders, which later turned into daily showcases at some point to help us further plan more work. When one of our team members moved remotely, we even did daily afternoon stand-ups to ensure that we kept synced with any major shifts in the day.
We experimented with many forms of chat software early on. We tried google hangout (but it seemed to turn one of our machines into furnace), we tried group skype, we tried google chat and we ended up settling up on chatzy as a way of having a persistent chat. We evolved a protocol of trying to have conversations in the chat room, so that when our remote member came back from meetings with stakeholders, they could easily answer and respond.
We experimented (probably half-way into the project) with leaving our video conferencing software (GoTo Meeting) on when one of our members were remote so that it felt like they were in the room and they could see us in the room. A spare laptop (our build server) and a simple crate fixture to prop it up so they could see us worked well.
We gave up using a physical wall in favour of an online card wall (Trello) as a mechanism for sharing work. Our ability to concurrently edit/update that turned out a great way of capturing and sharing notes.
Daily planning and story-writing sessions
Our “stories” were small. Our technical team of two developers, a user experience/front-end designer could churn through a lot in this context (moving between 20-40 stories per week) and we worked hard to ensure that we identified and split stories based on new needs and feedback from our stakeholders.
When we first started off, we started off doing a story-writing session to tackle our initial user journeys. The first session, I remember being remote and we were still able to “sit down” as a group and do a brainstorm. We set aside fifteen minutes, and split in two sites (me remote) and the rest of the team in one place we all got index cards out and brainstormed potential user stories. I used the in-built video camera in my laptop to share my index cards and they did the reverse as we talked through each one via video conferencing software. At some point, further on in the prototype, we moved to a daily planning session where we’d capture ideas directly into our online card wall.
Continuous Deployment
We still had a small build pipeline into production with a handful of unit tests to sanity check our final product that would automatically deploy the latest build into our “production” environment. I’m not sure, but I would guess that we deployed into production at least twenty times a day (as a team) and our stakeholders were surprised to see the system evolve even as they were interacting with it.
Even during some showcases, we were able to fix small issues (such as wording, placement) and have it appear a few minutes later.
Automated unit tests for quick feedback and design
Given it was a prototype, we were clear we didn’t need to have as much automated testing in place for a system that would have a very short shelf life. For us, testing goes beyond validating the behaviour you expect to a mechanism to drive design. If it’s hard to test, there’s probably something about the design that needs to change. For us, our tests provided two mechanisms – fast feedback about when to address code smells, and the other was to validate the simulated data model that needed to represent “realistic data.”
Given the domain our prototype worked in, our clients needed a balance where they didn’t want any real examples, but they wanted “realistic” samples. This means that we ended up modelling our customer’s domain in a way that let us generate new datasets easily. As an example, when we needed to extrapolate a “points based system” based on constraints that someone ran a search by, we only needed to touch one class to generate data that we tested as quite realistic against end users of the system. Prices had a relationship between the brand of the product and class of service, and this was just as easily modelled. Our unit tests allowed us to evolve characteristics of our model before plugging in new inputs to generate different outputs.
Poly-skilling or anyone could fulfill any responsibility
We all took part in story-writing. We started off with our analyst taking care of tracking progress, but we quickly moved that responsibility to a developer so that they could better use of their time testing the system with end users, and distilling the feedback from the large number of sources.
Our user experience designer was fantastically competent as a front-end developer and even let us lonely developers have a go at reworking some icons that needed adapting based on user feedback because his time was better spent looking at overall flow.
We took time out as a group to take part in exploratory testing trying to find weird user-nuances, edge bugs compiling them into a google spreadsheet before working with our stakeholders to feed them back into work.
Everyone on the team had a go at facilitating retrospectives and organising the feedback sessions that gave us the steer on which further direction to move in.
As a team, we made sure that everything that needed to happen happened without being precious about who did it.
Continuous reflection and continual improvement
Although we held a small handful of retrospectives, they weren’t our only opportunity to improve. If someone wanted to try something, we gave it a go for a day and then worked out if we wanted to continue doing it. Some things died off if someone felt we weren’t getting value from it. Other things just continued on because it seemed to work for us.
Developing social connections in the team
One activity we used to kick off our team was also to be explicit about some of our natural preferences – such as what sort of chronotype we were.
I think one thing that worked really well for us was having lunch together when we were in the same location. Mostly this was in Germany, which has a culture of having a sit-down lunch rather than the grab-and-go culture in the UK. I think this helped us bond as a team, and we grew to know each other more, sense each other’s working preferences and just get a chance to know each other much more.
“moving between 20-40 stories per week…” Could you describe what 1 story point was for you (size) Just curious.
We didn’t actually use story points. We just counted the number of stories. Some example stories would be things like:
I think we were able to run through many stories because it was a prototype and vertical slices were naturally much smaller (almost zero integration with external libraries)
Great story Pat, thanks for sharing! Remembers me of project in which I worked a couple of years ago. Team members were distributed around the world, and we used telephone conferences and wiki’s to communicate and share materials, and also to present to our steering group every couple of weeks.
We defined some Golden Rules for Agile Process Improvement to establish and develop our agile miondset, and involve others in continuous (process) improvement.
It was a project, and it was agile, but “not as we know it , Jim”.
@Ben – Thanks for your comment and sharing your own story.
Quite an interesting read. Couple questions regarding the communication aspect:
* How did you handle screen sharing with remote workers? Did somebody just log into the build server and change who was presenting in the GoToMeeting?
* How was remote whiteboarding handled?
Hi Steven,
Thanks for the read. We used our conference tool (GoTo Meeting) for most screen sharing events but that was mostly point to point, rather than everyone connecting.
We didn’t have the need to do too much whiteboarding remotely. Where we did, we drew on index cards and held them up to our in-built cameras to share, or emailed the drawings and talked through them.
Sir
For the current iteration I have two 1 point stories that are very similar. Both stories can be addressed by the same code. In other words changing the sql will satisfy the acceptance criteria for both stories. Question, does it make sense to only deliver one story at a time when to do so involves more effort. Does changing the code and delivering the two stories together break the agile process? I am having a hard time wrapping my head around this because separating the stories will actually create more work than delivering them together. Is there any documentation that can explain this to me better.