patkua@work

The intersection of technology and leadership

Page 15 of 53

Looking back at a year with a client

December 7, 2012 / / 1 Comment

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.

Agile Testing Days Summary

November 26, 2012 / / 0 Comments

My last speaking conference for the year was the Agile Testing Days held in Potsdam on the outskirts of Berlin. In terms of conference history, this was its fourth year of running and attracts a lot of the big names in agile testing circles, as one would expect from the name. For me, as a test-infected developer , I found it fascinating to see what concerns the testing audience and I felt many common themes around whether or not testing was important, the difference between an agile tester and a normal tester, and of course a focus on collaboration and working iwth other roles.

They had three keynotes a day, a pretty overwhelming number considering that there were multiple tracks and sessions. I don’t think I would do much justice trying to summarise them all but I’ll share a number of highlights that I took away. Jurgen Appelo spoke about the stories behind his books. He’s an entertaining speaker, very well prepared and I feel very in agreement with his “all models are broken but some are useful” approach to collecting different software methodologies and giving a go at lots of different things. Just as the community is continuing to expand beyond just software development, his focus is also pointing upwards into the upper hierarchies of management – to those with the money, budget and decisioning making authority. He’s invented something he’s calling the “management workout” although I shudder at this after seeing it associated (read: abused) by a very hierarchical organisation very much into command and control. Ask me about it one day if you see me in person.

I also appreciated Gojko’s keynote presentation challenging existing thoughts on collecting information, metrics and that all we are doing is improving the process of software development, not necessarily the product. His argument feels very similar to the lean start up movement that why bother putting quality around features we aren’t even sure are useful by anyone, or not validated. He quoted a number of clients he’s seen who throw away automated testing suite in favour of measuring impact on business metrics and trends – using that to work out regressions. It’s an interesting approach that requires a) businesses to actually identify their real business metrics (very rare in my opinion) and b) link features to these metrics and c) measure them very carefully for changes. I guess this also goes along with his new book on Impact Mapping to work out where to put the effort.

He also criticised the testing quadrants, argued that we’re collecting the wrong data, points out that exploratory testing is still testing the process (not the product) and that most organisations are missing feedback once they go live. He also came up with his own adaptation on the Maslo’s hierarchy of needs in terms of software. It starts off with building deployable/functional software, then it should meet performance/security needs, then be usable, followed by useful and then followed by successful. He also recommended a book new to me, called “The Learning Alliance: Systems Thinking in Human Resource Development”

I ran my session, TDDing Javascript Front Ends shortly after a BDD session that complemented the idea very well. The previous session focused on why/what and not the how, where mine was a good depth into how you do it from a hands on practitioner point of view. I had a number of good questions and people after the talk that gave me some great feedback and encouraged me to do more. The only shame was that the session was limited to 45minutes and the tutorial that I run with is normally achievable. I look forward to people taking the online tutorial (found here) and then passing in even more feedback.

Goto Aarhus 2012

October 9, 2012 / / 0 Comments

This year was my first time to both attend and present at Goto Aarhus. Over the years, many of my colleagues have said that it’s one of the best conferences with topics in lots of different areas. This year focused on topics such as NoSQL, Big Data, Humans at Work, Javascript, Continuous Delivery, Cloud and many more areas.

Two of the best presentations I attended, both for content and delivery were Sam Newman and Jez Humble, author of Continuous Delivery (Disclaimer: They are my colleagues after all). What I enjoyed about their talks were both their talk about real world examples, as well as important advice as well as the delivery. Getting the balance right is really difficult to do.

I also really liked the keynote from Dirk Duellmann from CERN who talked about the big data challenges they have storing information. Although it took a while to get to the meaty part of the data, storage details I think it’s a very interesting outlook they have with architectural choices such as the view that they cannot design for hardware or devices today as these will be obsolete as time goes forward. Being able to retrieve historical information is important as it the ability to store all of the data in a format others can read. They have realised the importance of the scale of the work they are doing, so they are focusing on doing something good (storing and making available data) and working with other groups to do the analysis.

There were loads of highlights such as meeting many new people and connecting with old ones as well as some interesting side conversations.

I gave my talk (above) and was very happy with the results. The Trifork team behind the conference are awesome at getting feedback to presenters for quickly and I was very happy with the results. The conference uses a simple voting system for feedback (red, yellow, green) and they keep track of the number of walk outs. I ended up with 90 green, 26 yellow, 1 red and only 2 walkouts. I have no idea how that compares with other speakers but I’m pretty happy with the results. What I also appreciated were the people who came up afterwards to talk to me about how the topic is really important and what some people got out of it (affirmation they are doing the right thing, new ideas to take back, new books to read, more things to focus on, or a good idea of how to prepare as they step into the role).

Book Review: Getting Naked

September 5, 2012 / / 0 Comments

Getting Naked sat on my list of reads for a while, and it was only recently that I tracked down a copy. A “business novel”, the book describes the style of consulting through a story line, and a pretty interesting one (for a business novel). It follows the tale of the main character Jack Bower, working for a big consulting firm who acquires a much smaller but better of consulting firm called Lighthouse. Behind the company is someone he considers a rival, and is put into an uncomfortable situation trying to learn more about the way that they do business.

The larger consulting firm does business as I see traditional consulting – one with a very highly leveraged model of few partners all the way down to an army (find a better word) of associate consultants who do their research and analytical thinking. Their style typified by land-and-expand consulting that is generally more about the sales than it is about doing business.

Jack Bower goes down to see how Lighthouse run their business, skeptical of their approach. Firstly they have a smaller set of consultants, and much less leveraged with a much lower turnover. He is horrified to shadow the first client where he doesn’t see any background research done, no “presentation” prepared but they just go in and start asking questions about their business and what their problem is.

The rest of the book unfolds with a whole set of principles around the Naked Consulting idea that I think makes a lot of sense. In many ways, I like to think I see this in what I’ve seen very good consultants do. The book has a nice way of concluding the principles that I’ll list here:

Fear of Losing the Business
Put yourself at stake even when there is a risk of losing business. Honesty builds trust that wins over the long term. Principles include:

  • Always consult instead of sell by demonstrating value through serving
  • Give away business – advice is cheap, so don’t hold back even before they are a client
  • Tell the kind truth – It’s important to tell the truth, even if it’s uncomfortable. Be respectful but never avoid stepping around issues that others might.
  • Enter the Danger – Kind of feels like XP Courage value but requires you stepping into the middle of uncomfortable situations to fearlessly address an issue others are afraid of.

Fear of Being Embarrassed
Don’t put personal pride about idea generation and suggestion. Principles:

  • Ask dumb questions – It’s better to become informed in something you don’t know and often many other people don’t know the answers to the same questions
  • Make dumb suggestions – Offer many small suggestions to test for new ideas versus waiting for the “perfect solution”
  • Celebrate your mistakes – Being wrong is okay, inevitable and perfection is not expected. Acknowledging these helps builds confidence in others to take part

Fear of Feeling Inferior
Trying to look superior, or with a high level of standing or expertise. Client needs above the needs of others. Principles:

  • Take a bullet for the client – Being a sacrificial lamb can help the client in some situations, but is balanced out with the kind truth
  • Honour the client’s work – Show interest in the client’s industry/business. It helps to choose clients that are aligned with your own company’s interest. In the book, for example, the smaller successful firm turns down clients in industries it just can’t work in.
  • Do the dirty work – Don’t consider tasks “beneath you” regardless of your skill/experience and do it humbly
  • Admit your weaknesses and limitations – Ensure you know where your strengths lie and avoid covering up your own weaknesses in order to thrive in the best environments.

Summary

The book was easy to read, simple and had a very clear message. I found lots of similiarities to the way that ThoughtWorks conducts business and the skill I’ve seen with some of our great principal consultants. It summarises the approach in a very, clear digestable manner and I’m pleased to have heard of many of these things before.

Spike Showcase

September 3, 2012 / / 0 Comments

A key concern of mine, as a Technical Leader is ensuring that knowledge is distributed on a team. Working on a large team makes that a challenge because so many changes happen at the same time, but you’re also dealing with multiple learning and communication styles. This means that one technique doesn’t work as well as another. Due to my passion for learning, I try to keep this in mind and try to ensure we use multiple channels for getting information to everyone.

One practice we’ve been experimenting on our project is one we call, “The Spike Showcase”. Spikes come from the Extreme Programming methodology and represent an investigation into an area the team doesn’t have knowledge of. We create one of these when we need to generate options for the business, or when we are dealing with a new integration point and want to assess the quality, testability, or best designs. That knowledge is normally take on by a pair and remains dangerously siloed on a fairly large team.


Image sourced from drubuntu’s flickr stream

The pair normally writes up their outcome on the wiki (for long term purposes) and they have an area where they can check in their code for reference, yet documentation is not very engaging and I know that most people on the team won’t look at the code unless they are going to work in that area because they are busy doing other things. Pair programming solves this problem to a degree, but on a large team would take a long time to distribute the information.

Our solution has been to hold a “Spike Showcase” where the pair who completed the spike hold a session with the entire development team, talking about what the problem space is, what they tried, and running through the design and solution. Depending on the type of problem being solved, the pair will use a white board to diagram the logical interactions, or show some screenshots of what they were trying to achieve from a business sense and then they will demonstrate the spike solution in action before finally showing the code and how it all works. We then run some question and answers with the team (allowing people to pull knowledge) before finishing up.

We have run several “Spike Showcases” now and I feel they are invaluable to ensuring a large team keeps abreast of various solutions going on.

Book review: Suckers

August 20, 2012 / / 1 Comment

I like catching up on some reading when I’m on a long-haul flight, so the trip to Agile 2012 gave me some time to do some reading. I picked this book called, Suckers from my local library intrigued by its title on telling the truth being Complementary and Alternative Medicine (CAM throughout the rest of the book). It’s a pretty detailed book, looking very well researched and I think gave me a pretty good comprehension of all the different CAMs out there including all the gritty details.

Some of the book didn’t really surprise me such as many institutes often set up and made to create “certifications” to allow people to credentialise themselves in fields that don’t really exist (sound familiar to you agile folk?). Although I tend to avoid CAM theories on the basis of not knowing so much, the book made be realise how much damage they could cause just by being there. For example:

  • People who don’t know what they are doing prescribing things that are completely inappropriate. Often triggered through some subscription-based service/product scheme.
  • Less harmful is where people take money for ailments that really do-nothing.
  • More harmful is when people put too much confidence in these therapies and skip medically researched alternatives that may actual help them. The book told of one sad story of a man with cancer skipping traditional treatment in lieu of a “machine that generated light” that cost the quack a fraction of what they sold it on for.
  • Risk around unknown substances making their way into these alternative medicines where they are not regulated, therefore all sorts of elements potentially find their way into the final solution. They cited a number of cases where people ended up poisoned from some “other” ingredient added to the final pill to make it cheaper to manufacture

Interestingly the book covered motives why people would go for CAM therapies such as a distrust of the government and medical industry (out to make money), people looking for a “silver bullet” solution and the face-to-face time they get from alternative therapists when face-to-face time with doctors in the UK sees downwards trends.

I learned that the CAM world is much bigger than I originally thought. Yes they cover traditional ones like homeopathy, acupuncture, Chinese medicine and chiropractic treatment but there are whole realms of things I didn’t realise people actually believe in such as magnetic treatments, “healing stone” therapy, light therapy, wind therapy, and Ayurvedic treatments. One big surprise for me was that chiropractic treatment has not scientific basis, and therefore isn’t a very well regulated industry so be careful if you’re going to get anyone to crack anything in your back. You only have one of them after all.

I would definitely recommend this book for anyone looking into Complementary and Alternative Medicines. It’s easy to read and very well suited for anyone living in the UK (as they refer to the UK medical system and legislation often).

Reflections on Agile 2012

August 19, 2012 / / 1 Comment

Another year, another agile conference. It’s time for reflecting on the conference and uncovering lessons learned. Dallas, Texas hosted this year’s Agile Conference. More accurately, the Gaylord Texan Resort in Grapevine hosted this year’s Agile Conference. Loved by many at the conference (notably less so by Europeans) the resort reminds me of the Eden Project and a weird biosphere (see picture below) that is self-contained and fully air-conditioned. Although maybe this wasn’t such a bad thing with a West Nile virus outbreak in Dallas.

Needless to say that I stepped out quite a bit to try to get some fresh, if not, refreshingly humid air.

Onto the conference. It was very well organised, very well run and even rapidly responded to feedback (such as moving rooms when demand proved too much for some of the anticipated sessions. Food came out very promptly in the different breaks. We didn’t have to queue too long and the variety was pretty good. The only breakdown was probably the Tuesday lunchtime where it wasn’t clear we had to get our own food and with a limited number of on-site restaurants in our self-enclosed bubble world, proved to be a bit of a tight squeeze in schedule.

The people at the conference seemed to be a bit of a mix. Mainly lots of consultants like myself sharing their experiences, but as one person noted, an extraordinary number of agile coaches all apparently looking for work. On the other extreme there seemed to be lots of companies adopting agile and lots of people selling tools and training to help them.

Lots of parallel tracks meant lots of choice for many people but I often found it hard to find things that worked for me. I’m less interested in “enterprise agile adoption”, and more interested in the practices pushing the boundaries, or the deep insight offered by people. The few technical sessions I went seemed to be aimed at a bit more of an introductory audience. I particularly avoided any of the “do this with scrum” or “do this with kanban” as these appeared by be pushing.

In terms of keynotes, I thought they did a great job of assembling some diverse and interesting sessions. Although Bob Sutton (No A**hole Rule author) felt like he didn’t do much preparation for his keynote from the text heavy slides that jumped at different paces, he had some good anecdotes and stories to share. My biggest takeaway from that session was thinking about taking away practices just as much as adding practices, something that I think I do implicitly but should try to do more explicitly. The other keynotes were pretty inspiring as well, with Dr. Sunita Maheshwari behind Telerad talking about her accidental experiment moving into doing remote radiology to support the night-shift need of hospitals in the US and the interesting growth of their business. The other really inspirational keynote was by Joe Justice, the guy behind the amazing Wikispeed project taking sets of agile practices and principles back into the car-making industry. I felt he really knew his stuff, and it’s amazing how you can tell someone who really understands the values and trying to live them in different ways and then translating them into a different world. Very cool stuff that you should check out.

In terms of other workshop sessions, I left half way through many of them as the ideas were either too slow, or not at all interesting (such as one on Agile Enterprise Architecture that spent 30 minutes trying to go back to the age-old debate of defining Enterprise Architecture.)

Two of my most favourite sessions was one by Linda Rising who gave a very heart-felt and personal Q&A session that left many people in tears. Her stories are always very personal, and I really admire her ability to look beyond someone’s words and really uncover the true question they are asking with a usually insightful answer as well! The other session was listening to the great work that Luke Hohmann of Innovation Games has been doing with the San Jose government to change the way they make decisions about where the money goes through the use of games and play. Very awesome stuff.

I had my session in the last possible slot on the Thursday and had a large number of well known people in competing slots such as Jeff Sutherland, Esther Derby and Diana Larsen. I’m very happy with the turn out as we had a lot of fun playing games from the Systems Thinking Playbook including a number of insightful conversations about systems thinking concepts and how they apply to our working life. One of my most favourite exercises (Harvest) that demonstrates the Tragedy of the Commons archectype played its course and we finished in just three years (iterations) only due to a constraint I added early into the game. I love this exercise for its potential for variation and the insightful conversations about how this applies to agile teams, organisations and functions.

You often can’t come away from conferences without new references, so here’s the list of books and web resources I noted down (but obviously my summary is without actually reading into it, so YMMV):

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑