Last year, I wrote about trialling the idea of Feature Leads. I think the idea worked out and I would encourage more teams to adopt this approach. It helped devolve some of the responsibility and made the work more engaging for developers. Looking back at the list of things to consider, I would now add more items.
What is missing list?
- New environment needs? – Do we require new environments to support business stakeholders in their own testing, or do we overload an existing environment? If we rely on external dependencies, can they support the number of environments that we need.
- Identify external dependencies – If we are working with external vendors, we need to probably be a bit more upfront in working out when key dates are so that we can co-ordinate
- Has the business made any external/internal commitments – As much as teams get frustrated by arbitrary dates set by the business, it’s useful to know if a) any have already been set, or b) business stakeholders want to communicate dates because that means you need to manage expectations and ensure that those commitments are balanced with other priorities going on.
- Is the solution simple, but evolvable – Does the approach make any anticipated work harder than it needs to be? Does it balance out time to market? Can we go for an even more lightweight solution and substitue a more complex one later if needed?
- Do we need to build anything for the feature? – Is software even needed, or can some lightweight business process take care of the need? If we build this, how long will be used, and therefore how much effort in maintaining it/adding automated tests around it?
Looking back at the list of responsibilities, I think these elements help add to a standard list of what things to consider when designing any sort of software solution, and not just the building of it, but thinking about the long term effects of it (who uses it, who’s going to run it, who’s going to maintain it).
Over the last twelve months, I’ve worked with a client to rebuild a digital platform and a team to deliver it. It’s now time for us to leave, and a perfect time to reflect on how things went. The digital platform rebuild was part of a greater transformation programme that also involved the entire business changing alongside at almost all levels of people in the organisation. The programme also outlined, before we arrived, outlined a complete change in all technology platforms as well (CRM, CMS, website) to be rebuilt for a more integrated and holistic service offering.
Our part in this program turned into building the new web digital platform, working against a very high level roadmap, and a hard marketing deadline. We ended up building the site using Ruby on Rails serving content driven by a 3rd party decisioning platform (much like Amazon recommendations) guided by the business vision of better tailored content for end users. We didn’t have much input into the final choice of several products. I’m very proud of the end result, particularly given the tense and short-timed framed environment in which we worked. Here are some examples of constraints we worked with:
- 4 Product Owners over the span of 11 months – From January this year, through to the end of October, the business was onto its fourth Product Owner for the digital platform. Building a consistent product is pretty much nigh impossible with changing product hands, and trying to bridge work from one Product Owner to the next was definitely a challenge.
- Constant churn in the business – The 4 product owners is one instance, but we would often be working with people in the business to work out what should be done, only to find that the following week they were no longer with the business.
- 3 Design Agencies engaged resulting in “reskinning” approved by the board before the 6 month public launch – We saw several “design changes” done by firms well stocked with people capable of generating beautifully-rendered PDFs that were signed off. However often these would imply new functional work, or be impractical to the web medium.
- Marketing deadlines announced well before the development team had been engaged - A common pattern in the business was marketing launching a press release announcing a date, well before the people involved in delivering it were made aware, or even consulted on it.
- PM Explosion – At one point, it felt like we had more Project Managers on the group planning out work with budgets and timelines that would be approved well before the development team had been approached.
Even with these constraints we’ve been able to deploy to production 37 times in the last three months and more since the original MVP go-live in July. Part of what I’m particularly proud of is the team where we were able to achieve the following:
- Building an Evolvable Architecture – We questioned the original choice and need for a CMS but with a constraint that a decision had been made on buying these tools, we architected a solution that would hide the implementation details of the CMS via a content service. With our TW experience and pain dealing with CMSes that are shadowed by business need, we wanted something that would not constrain what the business could achieve (hence the decoupling). We even had a chance to prove this out when the business requirements quickly hit the limit of the CMS’s built in categorisation module.
- Responding to Change – The business roadmaps seems to change on a daily basis, and our team was able to quickly tack to accommodate these business changes. We changed the team structure as the team size increased, changed the team structure as we went live, and again as people in the business changed. Whilst our process felt similar, it would look nothing like a textbook XP, Scrum or Kanban process.
- Improving the Process – Our team has been constantly trying to change the process not only internally to the development team, but also helping people in the business find ways of improving their own way of working. Progress has been slow as the change that starts falters as people leave. Retrospectives have been a key tool but also has the ability for the team to feel empowered with recommending and pursuing improvements they see fit.
- Setting an example of transparency – Showcases are key to the business, and we would offer fortnightly showcases to the features built to the entire organisation. Huge numbers of people came along and I found it fascinating that it was one place where people had an opportunity to talk across silos. This sometimes slowed down our ability to show what we had actually done, but I felt exposed missing communication structures that people still needed.
At a technical level, I’m really proud of some of the principles I wanted to achieve at the start and that the team lived throughout (I’d love to hear what their experience is). Some of these include:
- Fast developer setup – Getting started on each new machine should be fast without complicated installation processes
- Developers rotating through operations – There’s nothing like supporting the code you wrote to help developers understand the importance of logging, test cases that are missed and just experiencing what production support is like
- DevOps culture – Everyone on the team is capable of navigating puppet, knowing where to look for configuration changes and ensuring that applications are configurable enough to be deployed without special builds across environments.
- Continuous Delivery – Our second product owner (the first transitioned out the day we went live) actually asked for us to release less often (i.e. it is a business decision to go-live) so that they could work with the rest of the business to ensure they had their non-IT dependencies in place.
- Devolved Authority to Feature Leads – I blogged previously about Feature Leads who could help shape the technical solution and drive the knowledge for the project.
- Metrics Driven Requirements – Though not completely successful, we were able to stop the business from implementing some feature by showing them production metrics. In this case, we were able to avoid building a complex search algorithm to show that we could achieve the same result by adding to a list of synonyms on search.
- Everyone grows – If I look back at the project, I think everyone on the team has experienced and grown a significant amount in different ways. I think we struck a good balance between being able to work towards individuals goals and find ways they could help the project at the same time.
Other particular things I’m proud of the team:
- Taming the Hippo - Worthy of its own post, Hippo CMS has been one of the least developer friendly tools I’ve had to deal with for some time. The team managed to work out how to run an effective functional test around its poor UI as well as deploy and upgrade the beast in different environments without the 12 step manual process outlined on their wiki.
- Rapid team size – Management wanted the entire team to start at the same time. Even being able to push back, we ended up with a very aggressive ramp up and we still managed to deliver well.
- Diverse but co-operative – We had something like 17 people and 14 different nationalities and it’s one of the strongest teams I’ve seen who were able to work through their differences and forge ahead.
Things that I would like to be different:
- Find a way to code a lot more – Due to the circumstances, many elements drew me away from coding. At best, I can remember pairing with someone for at most two days a week (for a short time) and I would like to find a way to do that more.
- Implement more validated learning – Although dependent on a product owner willing to do this, I would have liked to work more on trying to build and experiment a lot more.
- Have a stronger relationship with decision makers with authority – I believe development teams work best when they are connected to people who can make decisions, not just organisational proxies who provide answers. Unfortunately I felt most of this cascaded very far up the organisation and due to the constant flux and organisational change, this wasn’t possible in the timeframe. I’m hopeful that as the business matures and more permanent people find their place, this will be more possible.
On my current project, I’ve tried something a little bit different inspired by the work of Feature Driven Development (FDD). Although sometimes cited as an agile methodology, my perception is that it is one of the lesser talked-about methodologies. On my current project we have been trying the idea of Feature Leads for the last four to five months, and I’m pretty happy with how it has turned out.
Feature teams versus Feature Leads
FDD often talks about Feature Teams – or a team that works on the design and implementation of a feature area. Since FDD heavily emphasises more modelling up-front, these tasks also often talk about Feature Teams leading the UML modelling and design documentation that goes along with it. In our circumstance, I didn’t think it made sense to have any real Feature Teams, namely because it was a greenfield project and there wasn’t any clear way features stayed independent of each other. I favoured the XP practice of Collective Code Ownership over what specialisation a Feature Team may bring together. I wanted the best of both worlds, so I introduced the team to the idea of a Feature Lead.
What does a Feature Lead do?
Our team had a good mix of experience, and introducing the “idea” of Feature Lead without communicating some of the responsibilities would definitely lead to some trouble. When I first introduced the Feature Lead term, I outlined a list of responsibilities that would come with it. I even printed a list to give to each Feature Lead to act as the starting point for a Standard Work checklist.
I included the following activities:
- Explore all the use cases – Arrange workshops with the business owner to understand all business objectives the are trying to accomplish. Design a solution with that stakeholder, balancing business process supported by technology. Challenge assumptions about technology constraints and solutions, and avoid building software if there isn’t a clear need (i.e. we don’t want to build the wrong thing faster). Work with me (as the overall Technical Leader) to validate the solution. Consider the end-to-end flow including business people who need to be involved in set-up, on-going maintenance or business support as well as expected outcome.
- Explore the impact on deployment and architecture – Does the business needs/technical solution warrant a change in architecture?
- Identify spikes as early as possible – Are there any investigations we need to explore to create more options, or to validate assumptions before committing to a solution? Separate work that is not estimable into a spike and a story (and highlight the dependency on the spike).
- Consider external configuration – Will this work require new configuration work? How often will it change? Where will we store it?
- Who/where is the authoritative source? – If there is new data, or a new data store, be clear about which system is the authoritative source
- Does it make sense to re-write the backlog items? – We had already been given backlog items broken down, but often we found them with an assumed solution in place. After exploring what the business really wanted to do, the nature of the stories would most likely change.
- Verify assumptions against new stories – With the set of stories identified, work to validate all assumptions with the business stakeholder.
How I worked with Feature Leads
After the pair iterated over possibilities and designs, I would review their solution and stories with them, ensuring that cross-functional requirements such as security, performance, etc were all taken into account and represented. I would also work with the Feature Leads to ensure the overall design worked with the other Feature Leads and that we never diverged.
Once validated, I worked with the different Feature Leads to organise a Feature Walkthrough, talking about the business problems, the outcomes and how the stories fit together to make a comprehensive solution. This Feature Walkthrough distributed knowledge to the entire team so that they had enough context to pick up a story in any feature area and understood how it worked.
Feature Lead + 1
To ensure that we never had a bus factor of one, we always identified two Feature Leads (a primary and a secondary). Both needed to involved in the design and discussions as well as the story identification process so that if one went away on holiday, or was ill, that feature area would not come to a halt. As a fallback, I would also pick up the solution if both were away.
How has it turned out?
I am personally really proud of the team, and the way that the Feature Leads lead the design. We had some great solutions and ideas, and their outputs allowed the entire team to continue to own the codebase as a whole. There are so many other dimensions to talk about, but will get around to writing about them separately.
The morning started off with a keynote from Sally Spinks of IDEO talking about design thinking and their wholistic design approach to organisations and service design. From what I understood, her role involves “Organisational Design” which is an interesting concept that I initially balked a little at. How can you “design” an organisation and just expect people to play it out. Fortunately she answered that later in the talk about preparing for people to surprise you and to make sure you plan for that change. She talked a little bit about the history of IDEO moving from product design to service design to organisation design and describing how business models are the new units of design.
Being effectively a “change agent”, her most compelling message hit home for a lot of us. Set purpose. Do small stuff, tell big stories. Iterate on the purpose, do more stuff and tell more stories and keep going.
Another highlight for me was a short speech by a well known Swedish chef (in Sweden at least) called Jan Boris-Möller. He’s famous for a TV show going into people’s homes and cooking a three course meal in a a short time based on everything they have in their kitchen. He talked about leadership (setting direction for the kitchen), adaptability and understanding your constraints (e.g. catering for weddings on a farm where you limited access to power sources) and balancing personal creativity with customer success. He talked about understanding your customer and the contraints they work in. He gave the example that it is extremely rare for Swedish people to drink at lunchtime, but often drinks wine at dinner. This means that if you serve the same soup at dinner, it needs to probably be more intense in order to compete with the acidity in the wine.
He even prepared the wonderful evening meal for the conference dinner including wonderful creations including ceviches, foams and an intensely flavoured shot of soup. He
I also hosted an open space session called, “Succeeding as a technical leader” and had some really great conversations covering topics such as what makes a technical leader different from other leaders, their key responsibilities, their challenges and growth paths or how organisations help (or don’t) help them grow. We discussed items such as dealing with conflict, whether or not the role was needed and heard some great stories from the other open space participants.
I also later participated in the workshop, “Combining Usability and agile” involving both a little exercise and a healthy discussion on the different ways that teams integrate usability with agile. It was a small group but lead to some great examples and discussions.
I finally picked up a copy of Drive to read. The book looked ominously big, however I found out the two hundred (ish) pages had been printed on fairly thick paper and was pretty engaging to read overall. Pink focuses on a topic close to my heart, describing the way that people find engagement and what drives people. It’s quite relevant to the way that I like to work, and what the company I work for strives to achieve.
Pink covers a lot of interesting material, including many references and backed up by a lot of research. In it, he compares classic management techniques (financial incentives) and details research that describes why they fail to achieve what they need to do. He talks about interesting research that shows that a small financial incentive helps boost short term performance (in work that requires no thinking) at the cost of long term performance and detriment to creativity. For today’s information worker, and the chaordic environments we work in, this should really be raising alarm bells. To me, it’s akin to the systems thinkers that know that measuring and rewarding workers on the wrong incentives causes lots of problems. It also rings anecdotally to what I’ve seen some really talented people who work in these financial institutions driven into strange behaviours due to “bonus schemes” and loops.
Pink reiterates over points such as once we hit a certain wealth, happiness is no longer correlated with wealth. We seek, instead greater things. He gives many examples about how money isn’t a motivator for many people citing the achievements of Wikipedia, open source communities that build software such as Firefox and many more. He talks about once this is achieved, people are driven to solve problems, and be creative. He gives examples where people are driven to complete puzzles and games, not because they are paid to do it, because of some intrinsic drive.
Pink continually describes what gap there is between research and business and provides a way forward describing a number of elements necessary to satisfy this intrinsic drive. He talks about the need for autonomy, the idea of achieving mastery, and developing a true sense of purpose as well as providing a toolkit for people and managers to achieve this. I like to think that the agile values help businesses to focus on creating environments that help satisfy this new style of management. The idea of Software Craftsmanship emphasising lifelong learning and mastery, a common theme in agile teams to be autonomous in task completion and done right with lean thinking, building the right thing for a good purpose.
Above is a wonderful RSAnimate video helping to summarise the book.
I got included in on a twitter conversation by Mark responding to Brian talking about how ThoughtWorks people at a particular conference huddled around together. It’s not the first time people have observed that. A natural reaction by people outside of that circle is to comment on this, such as, “You’re not very inclusive,” or “Crowding around together is so rude.” Having been part of these circles before, and being told this judgement (with accompanying observation), I can tell you where it stems from.
ThoughtWorks is a distributed company
Though I can only observe consultants I interact with from other companies, I feel ours is definitely very global. We encourage people to travel from one country to another, frequently rotating projects and encourage each other to present at conferences. Being located pretty much all around the world, it’s natural you don’t get to meet everyone face to face. Even here in London, I am now used to turning up for a new office event only to meet several new people. We work on different projects, so it’s natural not to meet anyone.
Our electronic-social ties are extremely strong
Internally we have, at least what I like to think of as a very active mailing list. When I post something on there, I generally get some pretty good responses particularly from the largest community of software developers. Over time, you get to know someone’s online persona. You have a picture of them in your head, and start to see the nuances of how they express themselves. Even things like twitter help to do this. It’s not uncommon for me to feel more strongly attached to people actively participating in email conversations than some people in the same office of who I rarely see or talk to.
Conferences are attended by ThoughtWorkers from around the world
As I briefly touched upon before, as a global company we try to encourage people to travel and present at conferences. This naturally leads to opportunities for people to meet in person for the first time. It’s strange meeting people you feel like you’ve known for a long time in person for the first time. I still remember, for example, my first day in the London office where I finally met Liz Keogh and Tim Emiola for the first time after conversing with them electronically for 18 months before hand, and them now inducting me into the whole Britishness of “buying rounds” and the way that it all eventually works out.
People have a need for connectedness and belonging
Having just recently talked about it at the XP2011 conference, I noticed that we weren’t the only people to congregate into small circles. For instance, I remember a whole bunch of people from Brazil hanging around together for almost the entire conference. Likewise for a small group of people who worked for the same company in Sweden. It’s a natural thing, particularly in new environments, for people to stay close to those they already have relationships with.
It’s less about you than you think
It is all of these effects combined that lead to ThoughtWorkers aggregating at events. Perhaps it’s also because we tend to be quite loud/opinionated/noisy that it’s more noticeably. Gravitating towards each other isn’t a conscious act trying to exclude everyone. In fact, I know ThoughtWorkers like hearing other opinions, particularly if they’re even more different and based on strong experiences and though happy to contribute to conversation will be welcomed with open arms.
We can get better at this
I know it can be hard approaching a loud, opinionated group of people. I know we can do it better. Being aware of how we’re sometimes perceived, this is how I go about trying to break the perception:
- Invite others in – If I know someone standing at the edge of a group, I’ll introduce them and explain my relationship to them to others. It helps break the awkwardness and creates more opportunities for everyone to talk about similar interests.
- Randomly break away – If groups get too large, or hang around too long, I like to break away and meet some new people. I also try to encourage other people to do the same. It’s not only a good way of getting different perspectives, but helps address some of the above issues.
- Explain to others the contributing factors and perceived effects – By talking people through the above elements, it helps others understand why perceptions come up the way they do. More importantly it lets them decide how they’d like to deal with it
Whilst I can only speak for myself, I do hope that other people can benefit from this by being more inclusive where possible in these sorts of situations.
I’ve been interested in Systems Thinking explicitly for the last two or three years. I haven’t had many good books I could recommend to anyone other than “The Fifth Discipline.” Last year, I inherited a wealth of Jerry Weinberg books from fellow geek, Romilly Cocking and just got around to digesting a very classic book, Quality Software Management: Systems Thinking. Weinberg, whether or not you know it, has had a huge effect on our industry. He has written many books on wide ranging topics, and being a participant/organiser of the Amplify Your Effectiveness (AYE) conference continues to influence many leaders.
Anyway, back to the book.
Hard cover books are always a lot more intimidating than their soft covered brethren. Perhaps it’s the sheer bulky that does it. Fortunately the text is rather large and with only about 280 pages of content, easily consumed on a number of continental flights between the “no-electronic gadgets” zone.
I’ll admit that describing Systems Thinking is hard. Walking through, what Weinberg calls, Diagrams of Effects are intuitive when he explains them step by step, however I find it hard to describe the process and never have been very confident in some of the ones that I have used.
The Mechanics of Systems Thinking Diagrams
One tip that Weinberg talks about is thinking about the things in the boxes as things that you could measure (or you do measure) and their relationship between each other. Giving the item in a circle a name has been a challenge for me, and Weinberg presents a heuristic I feel I can make better use of.
Unlike models I’ve seen from places like Soft Systems Dynamics, Weinberg doesn’t use a plus or a minus, and maybe you’ll find his notations work for you. I can’t say they worked or didn’t exactly work for me. I did appreciate the different take on making the secondary, or implicit loops more explicit by attaching repeating loops to the lines they amplify, rather than to the entity they end up with.
In other Systems Thinking Diagrams, people sometimes note a delayed effect, something I was surprised didn’t really turn up in the book to a great deal. I don’t know whether or not this was intentional or not. A new difference I learned though was putting on another notation for diagramming where managerial decision/input affects the Systems Diagram. The way that Weinberg wrote about using this brought a little bit more of a humane aspect to it.
Repeating the role of Mental Models
In the Fifth Discipline, I didn’t really understand the importance of Mental Models related to the point of the Learning Organisation. After chatting to Mark Needham recently on the way that people interpret different things, and seeing how crucial this was to interpreting and drawing Systems Thinking Diagrams in Weinberg’s books, I better understand why these two things cannot be detached. In fact, it was very timely with the question that XP2011 keynote, Esther Derby kept asking, “In what world would this make sense?” to see things from a different Mental Model.
Weinberg tells a really good story about how these Mental Models effect the observation. He recalls a story talking to a manager who’s managed to work out how to distinguish good programmers from the bad ones. The manager starts talking about how he’s noticed how some programmers talk a lot to end users, or to other programmers. A grinning Weinberg, nodding at the manager’s observation slowly stops as he comes to realise how the manager don’t think of these inquisitive, communicative programmer’s as the better ones, unlike what Weinberg (and maybe you and I were thinking). Same observations, different interpretation.
Reconfirmation of in built human biases
We are full of biases that we aren’t even aware of. Many of Weinberg’s anecdotes remind me of some in particular. For example, he talks about how managers running projects that continue to fail, blame it on “bad luck”, or “something out of their control”, whilst taking personal credit for those that do succeed. This is a really good example of the Fundamental Attribution Error.
Things that didn’t work for me
Throughout the book, Weinberg refers to Pattern 1 and Pattern 2 type organisations. Even though he explained them early on in the book, I found it difficult to anchor any real meaning to them by the time I’d finished the book. I would have liked to have seen him give them better names and use them throughout. It’s a minor detail, however I did notice this slowing down my reading.
I’d recommend this, still highly relevant, book to people involved in IT today. Though it’s published in the early 90s, I’m surprised at how many of the stories are still relevant. It not only explains the basics of thinking with systems using models anyone can relate to. It also explains those systems diagrams that apply to the software problems of today.
Mark’s tweets got me thinking when I tweeted a short number of responses back at him recetly. Unfortunately twitter isn’t a great place to have a long and well thought conversation and figured I would blog about it like Mark did.
The gist of the conversation seem to float around two positions that seem to be in conflict.
Most people read this position and (incorrectly) deduce, someone’s behaviour is solely determined by their environment (or system) therefore, it is best to focus on one of them.
Mark makes a great observation that people perform “differently” given they have the same environment. In an environment, sometimes those “differences” may be “better”.
To which I responded in the brevity required by 140 characters, “different strengths and interests at play. Emergent behaviour based on individual and environment.”
Emergent behaviour in this case can be seen as much more than just strengths and interests at play. People are complex systems and highly unpredictable. Each individual goes through many different experiences. Just as an example, everyone’s commute around London is different. Train failure? Tube strike? Traffic on the street? Walking to work? Everyone has different social structures – sleep deprivation from young kids, happiness from a child’s graduation, hard night out celebrating a friend’s send off. Even the weather has a huge impact on people (though everyone responds differently).
It’s rare that I think we are all in the “same” environment all the time.
Add in the topics you’re currently interested in, the events unfolding around you and regardless of the system, and the skills, strengths at play and ambitions, I hope you start to understand why everyone behaves differently. Of course some of those elements in the system have minor impact on the end result yet might explain why some perform “better” (i.e. differently) to others.
I’ve been terribly busy the last couple of months and it reflects by the lack of any blog posts. So sorry for that. Here’s a short post talking about upcoming speaking engagements.
My first one is for the Collaboration Track at Orevdev in Malmo next week. Titled, “Tightening the Feedback Loop”, I’ll be exploring how interpersonal feedback can be so much more effective. The programme for Oredev looks amazing so I look forward to contributing and participating in the conference.
The second speaking engagement is for the Skills Matter Agile, Lean & Kanban Exchange talking on their “Leadership, Value and Visibility Track”. I’ll be covering, “Making ‘Management’ Work with Agile.