The intersection of technology and leadership

Category: Agile (Page 1 of 22)

Moving on from N26

More than a couple of years ago, I started on the journey as a “shake-up” CTO at N26. I often describe the role at the time as, “Shaking the snow globe.” The patterns of an early stage start up would no longer scale, and the company needed someone to help guide the transition. I was very honoured to guide the tech team through hypergrowth, and helping us transition from “start up” to the “scale up” stage of a company. Flash forward to today, and I’m happy to say we achieved that (and more).

I’m happy to say that the tech team is significantly more robust, and I leave knowing it’s in a much healthier state than what it was.

“Every new beginning comes from some other beginning’s end”

Semisonic

There are, of course, always many areas to continue to improve on. I’m happy that we have grown and hired many strong technical leaders who will continue to improve and iterate on this.

What I’m proud we accomplished

Although there are many elements I’m proud we accomplished, here are some of the ones that were definitely highlights.

An organisation with too many ideas will remain just that.

A better balance of tech to non-tech

When I first started, each C-level introduced new team members to the rest of the company. In the first few months, I was introducing one, maybe two, new people per month when the business team was introducing maybe 10-15. If, like me, you have worked in a place where you have more people with projects than capacity to work on them, you know what that would result in.

I worked closely with the people and especially recruiting team. We reworked everything from compensation and benefits, employer brand, recruitment processes and onboarding. Although we ultimately improved how we recruited and retained people in tech, I believe many improvements also benefited other departments as well.

Diversity doesn’t matter if you don’t have inclusion

We’re not just diverse, but also more inclusive than before

Like London, Berlin attracts all types of international people. In the last report I read, we had more than 60 nationalities in the tech department. I also wanted us to have diverse educational backgrounds and gender diversity, but I know focusing on diversity alone is not enough. We also needed to make sure we focused on inclusion.

Early on in my time, I sponsored the very first company wide International Women’s Day event. You can read more about it t. We set up a diversity channel on slack, added a bot that provided alternatives to gendered language like “guys”. (Sidenote: It’s amazing how many times we had to reinstall that bot!) I believe these actions let more people bring their full selves to work and resulted in support for CSD, many other Employee Resource Groups to support better work-life balance.

We avoided growing chaotically, instead doing so deliberately with a Target Operating Model

As the tech team grew, I knew that we would need to change our organisational structure to maximise both autonomy and alignment. As the team grew, we restructured deliberately to address issues team members faced as bottlenecks moved to different parts of the organisation. We introduced new roles and capabilities to focus on issues, giving people new growth paths and new areas to work in.

Growing people is like growing plants. A healthy environment combined with enough time and care.

I was able to personally support many people in their own growth

Growing companies offer people new opportunities for growth. However knowing that many roles like management or technical leadership are not a promotion but a role change, I’m happy to have supported many technical leaders in their own growth. I personally ran the Tech Lead Development Program approximately 5 times throughout my time. I mentored and coached people through many tough situations and I’m happy to have seen so many people grow and evolve. I even received some feedback that my support not only helped them professionally, but also in their personal life and relationships!

What’s next?

I very much appreciated my time shepherding the tech organisation, influencing the leadership team and direction of N26 and valued the experiences and tough situations I faced. I’m grateful for the experiences of working so closely with founders and other wonderful executive team members.

Many leaders ask themselves if they are having the best impact they can have. Are they able to bring their strengths to play in their role? I know where my strengths lie, and given my personal goals, it’s time for me to apply these strengths in a new context.

I will announce what exactly I’ll be working on in the new year, so watch out for a future post.

From Teams to Groups to Segments – An evolution using the Target Operating Model

A few weeks ago, I published an article about how we grew Product & Tech (P&T) at N26 during hypergrowth. I introduced the idea of a Target Operating Model (TOM). The first article focused on the why and what of this tool. In this article, I will share how we’ve evolved the core “building block” of P&T at N26.

From nominal teams to stable Product Teams

When I first started at N26, we had a set of cross-functional teams. This meant that we had people from Product, Design and Tech all sitting together (yay!) We had some organisational smells we wanted to address.

A code smell is a potential indicator of a larger problem. A code smell does not always lead to a problem. Rather you have to investigate and decide for yourself. An organisational smell is similar but to do with the organisation itself.

One such smell was a person moving from one team to another on an almost weekly basis. It also felt like a team’s focus would change on an almost weekly basis. Teams were rarely stable. The result was a lot of activity, but not a lot of outcome.

Our first TOM formalised the expectations of a Product Team. Each Product Team had an ideal size (up to 8) and a product area to focus on. Each team then focused on the evolution and support of that product area. We mapped out the complexity of our product set, to our team size and realised that we had many gaps to fill

The “Team” model

A large goal of our first TOM was to bring sustainability to product development. We needed to move away from relying on a handful of individuals (common in a startup) to a more sustainable model. Comparing our rate of hiring to our current needs, and needs for the future showed a huge gap. We kicked off an initiative to improve our recruiting, onboarding and retention approaches.

Part of this model revisited responsibilities of the informal leadership of each team. Instead of having a Product Owner and Tech Lead, we added in an Engineering Manager at a Product Team level. We wanted Tech Leads to focus on managing and aligning technical complexity. We also wanted to provide people with the environment and people support. When a Product Team was small, this was manageable As a Product Team grew, Tech Leads could not focus on both areas well.

From Product Teams to Product Groups

As we filled empty roles in Product Teams, we addressed what we wanted to. Engineers felt less overwhelmed. People could take holidays without worrying about being a single point of failure. We had deeper conversations around architectural direction. We also started having conversations about individuals’ career growth. People had more consistent 1–1s and feedback.

As we grew and changed, we noticed some new trends and organisational smells. As an example, some Product Teams reached the boundary of a reasonable team size. We needed to start splitting teams to minimise communication overhead. Some Product Teams also demanded a stronger focus on skills. As an example, our Payment Product Team was more integration heavy. Our Onboarding Product Team needed more front-end skills. Each Product Team needed more flexibility in how they structured themselves. Sometimes a product area needed a short-lived task force. We wanted to push more self-organisation downwards.

As a result we introduced the idea of a Product Group in our second TOM. A Product Group has 30–40 people from a cross-functional mix of Product, Design and Tech. A Product Group still had ownership over a product area. A Product Group had more autonomy to shape their own team structures and ways of working. We also made sure Product Groups knew company or global standards.

The “Product Group” Model — more autonomy and flexibility appropriate for the area

This meant that it was perfectly ok to have a Product Group with 5 teams. Or to have a Product Group with 3 teams and one small task force. Each Product Group had more flexibility to better fit their product area at the time. We expected Product Groups to be explicit about their choices and trade-offs. To aid this, the second iteration evolved the role of the Engineering Manager. Rather than being at a team level, the Engineering Manager moved to a Product Group level. This non-trivial decision deserves its own article, so I won’t discuss it further here.

From Product Groups to Product Segments

Our organisation continued to grow. An internal sample of different Product Groups showed more heterogeneity. Product Groups continued to ship product. Product Groups had more capacity to breath. Product Groups had more capacity to deal with more complex topics. Product Groups handled unplanned work better, minimising impact to other Product Groups. Product Groups had more people with relevant skills for their product areas.

The number of Product Groups continued to grow. We noticed that some Product Groups should co-ordinate more with some other Product Groups, but weren’t. As our business grows, domain complexity grows. We wanted to find a way to keep inherent domain complexity highly cohesive but low in coupling . Product Groups alone were not solving this. We also knew that some areas needed further domain knowledge and specialisation. Hiring needs started to differ.

To address these issues we introduced the idea of a Product Segment in the latest version of the TOM. Product Groups working towards the same goal sit within the same Product Segment. Product Groups within the same Product Segment should better communicate and align their plans with each other as they should be more related to each other (highly cohesive). Hiring plans will now be made on a Product Segment basis.

The relationship between a Product Segment, Product Group and Product Team

Reflecting on our journey evolving our TOM

Our latest TOM is still recent, so it’s early days to see it’s impact. When designing software architecture, you consider explicit trade-offs as part of decisions. This is also true if you consider organisational and team structures. No organisation or team structure is perfect. You need to ask yourself, “What are you optimising for right now?” “How are you maximising autonomy and alignment?”

“What are you optimising for right now?”

Building Evolutionary Architectures tells us to design software systems for constant change. Organisational systems are no different. A company rapidly growing needs to optimise for different issues at different scales. It won’t help you to copy our structures if you don’t share the same issues. Gather input and reflect deeply to consider what you need to optimise for. Evolve, document and communicate the TOM best suited for your situation.

Introducing the Target Operating Model – An Architecture Decision Record for the Organisation

I’ll be presenting a new talk at QCON New York next week titled, “Cultivating High Performing Teams during Hypergrowth.” One of the topics covered will be a tool I introduced as the CTO for N26, called the Target Operating Model (TOM).

In this article, I will share its origins, its purpose and where we found it useful. I plan on sharing some details about our current model in a different post next month.

What’s the problem?

The CTO role is one of the most misnamed roles of all C-level roles. Its responsibility vary across companies and industries. When I first joined N26, I described my role as being the shake-up CTO. Imagine a snow globe where the snow had settled on the ground. The snow represents a company’s habits and processes optimised for finding a product market fit. Super useful abilities in a very early stage start up with lots of unknowns. Pivoting a product until customers rapidly sign up.

Snow globe with a corgi dog, where the snow has settled at the bottom
A snow globe, ready for shaking (thanks to James Pett under the CC licence)

As more and more customers join, they give feedback. The rest of the business continues to grow as well. More ideas on product enhancements or improvements flow in. During this stage the core business does not change. The biggest challenge at the stage is quickly trying new ideas *whilst* not breaking anything. Growing both speed and stability are key factors here.

Early stage habits and processes break down. Daily changes in direction leads to a lot of activity with few outcomes. Two people making a decision face-to-face excludes gathering input from others. Verbal communication results in missing context for other parts of the organisation.

Imagine a world where customer numbers double every six months. Or where the number of employees doubles every twelve months. Would your organisation be able to sustain that?

What’s the solution?

Our snow globe needed shaking. I wanted to keep useful habits and processes. We also needed to establish other habits and processes that would better scale. I needed to transition our company from startup to scale up.

To do this, we could tackle this one issue at a time. Wait for an issue and react. Or we could copy what other organisations do (e.g. let’s do with Spotify does). I wanted to address our issues and our context. I wanted to do this as intentionally as possible. I also wanted to do this in a way that scaled, not one issue at a time. This gave birth to our Target Operating Model (TOM).

What is the Target Operating Model (TOM)?

The TOM provides a shared view of how Product & Technology (P&T) should work in the next 6-12 months. The name fit well for what I wanted to communicate. Let’s break it down.

  • Target – The TOM doesn’t focus on where we are now. It focuses on where we are heading as an organisation.
  • Operating – The TOM doesn’t compete with our product roadmap. The TOM focuses on how P&T works best in the anticipated context.
  • Model – A model is never perfect. A model is an approximation. Our TOM works with the Pareto principle (80-20).

I versioned our first Target Operating Model (1.0) as I knew we would want future evolutions. As we evolve our product, we would also evolve our operational model.

Important elements of the TOM

Like a good Architecture Decision Record, the TOM outlines the organisational context. We included the current state of the organisation. We highlighted what’s working well in the organisation (what we should keep). We also summarised current pain points across the organisation. We also included some discussion about where the entire company was heading.

After outlining the situation, our TOM focused on what was next. The TOM introduced a few principles for decisions, not only the decisions themselves. I find articulating principles useful for highlighting why we made certain decisions. The TOM introduced new roles (skills, capabilities and responsibilities). The TOM also set expectations for changes in existing roles. Many people often ask, “What’s in it for me?” or, “What’s changing about my role?” and I wanted to provide people clarity on this.

An important part of the TOM is new terminology about structures. I’m a big fan of DDD and the idea of a ubiquitous language. For example, “Do people have the same mental model when you describe a team?”

The TOM also provided visualisations how how our organisation would “look” different. Visualisations provided a way for people to link different concepts together. Imagine the visualisations as the new patterns that settle, after shaking the snow globe.

We also added gaps and next steps in our TOM. A TOM won’t every be comprehensive. As the old saying goes, “Perfect is the enemy of good.” A TOM cannot address all pain points so we found it useful to acknowledge known gaps. Next steps provided answers to the question, “What will change and when?” and, “How does this impact me?”

What was the result of using the Target Operating Model?

I introduced the first Target Operating Model over 18 months ago. As of this article, we’re now on our third iteration (TOM v1.2) and more than five times the size we were back then. Nothing grows at the same rate in a hypergrowth environment.

Given that, the TOM has been a useful tool. The TOM provided a shared vision about where we were heading. Hypergrowth creates a lot of uncertainty. The TOM created some certainty in a very turbulent environment.

The TOM provided a shared basis to have useful conversations. The TOM set expectations about change, even when you couldn’t predict when change would happen. More importantly, the TOM provided transparency across the entire company. It wasn’t information held by a select few. Everyone had the opportunity to understand, reflect and a chance to demonstrate leadership and a step towards the desired direction.

Find the follow up of applying the TOM in Part 2: From Teams to Groups to Segments – An evolution using the Target Operating Model.

Learning about More with LeSS

Background

I took part in a three day course before Christmas to better understand Large Scale Scrum (LeSS). LeSS’ tagline is “More with LeSS”. I’m pessimistic about most “Scaling Agile Frameworks.” Many give organisations an excuse to relabel their existing practices as “agile.” Not to fundamentally change them. Bas Vodde (one of the founders of LeSS’) invited me to take part in a course just before Christmas. I took him up on the offer to hear it “From the horse’s mouth.”

This article summarises my notes, learnings and reflections from the three day course. There may be errors and would encourage you to read about it yourself on their LeSS website, or post a comment at the end of this article.

About the Trainer

I met Bas Vodde about a decade ago. We met at one of the Retrospective Facilitator’s gathering. He is someone who, I believe, lives the agile values and principles and has been in the community for a long time. He still writes code, pair programming with teams he works with. He has had a long and successful coaching history with many companies. He worked with huge organisations where many people build a single product together. Think of a telecommunications product, for example. Through his shared experiences with his co-founder, Craig Larman, they distilled these ideas into what is now called LeSS.

What I understood about LeSS?

LeSS evolved from using basic Scrum in a context with many many teams. I took away there are three common uses of the term LeSS.

  • LeSS (The Complete Picture) – The overview of LeSS including the experimental mindset, guides, rules/framework, and principles. See the the main website, Less.
  • LeSS (The Rules/Framework) – The specifics of how you operate LeSS. See LeSS Rules (April 2018).
  • LeSS (for 2-8 teams) – Basic LeSS is abbreviated to LeSS and is optimised for 2-8 teams. They have LeSS Huge for 8+ teams, and modifications to the rules. See LeSS Huge.

Practices & Rituals in LeSS

LeSS has a number of practices and rituals as part of its starting set of rules. Some of these include:

  • A single prioritised Backlog – All teams share a single backlog with a priority managed by the Product Owner.
  • Sprint Planning 1 – At the end of this, teams have picked which Backlog Items they work on during a sprint.
  • Sprint Planning 2 – All teams do this separately. Like in Scrum, Sprint Planning 2 focuses on the design and creation of tasks for their Sprint.
  • Daily Scrum – Each team runs their own Daily scrum as per standard Scrum.
  • Backlog Refinement – Teams clarify what customers/stakeholders need. Good outcomes include Backlog Items refined into sizes where teams can take 4/5 into a Sprint. LeSS encourages groups, made up of different team members, to refine Backlog Items. This maximises knowledge sharing, learning and opportunities to collaborate.
  • Sprint Review – Teams showcase their work to customers/stakeholders for feedback. The Product Owner works to gather feedback and reflect this in the overall Backlog. Sprint Reviews should not be treated as an approval gate. It’s about getting more input or ideas.
  • Sprint Retrospective – Each team runs their own retrospective. As per standard Scrum.
  • Overall Retrospective – Members from every team plus management hold a retrospective. This retrospective focuses on the system and improving the overall system.
  • Shared Definition of Done – All teams share an overall Definition of Done, which they can also update. Teams can build on the basis of the shared Definition of Done.
  • Sprint – There is only one sprint in LeSS, so by definition all teams synchronise on the same sprint cadence.

Roles in LeSS

  • Scrum Master – Like in Scrum, LeSS has the Scrum Master whose goal is to coach, enable and help LeSS run effectively. The Scrum Master is a full time role up of up to 3 teams.
  • Product Owner – The Product Owner is the role responsibility for the overall Backlog prioritisation
  • Area Product Owner – In LeSS (Huge), Area Product Owners manage the priority of a subsection of the Backlog. They also align with the Product Owner on overall priorities.
  • Team – There are no explicit specialist roles in LeSS, other than the team (and its members).

Principles of LeSS

A key part of LeSS is the principles that guide decisions and behaviours in the organisation. People can make better decisions when taking these principles into account. You can read more about LeSS’ principles here. Like many other agile ways of working, Transparency is a key principle. Unlike other agile methods, LeSS calls upon both System Thinking and Queuing Theory as principles. Both are useful bodies of knowledge that create more effective organisations.

Another explicit difference is the principle of the Whole Product Focus. This reminds me very much of Lean Software Development’s Optimise the Whole principle. I also like very much the description of More with LeSS principle. This principle challenges adding more roles, rules and artefacts. So think carefully about these!

Overall observations

  • In LeSS, having LeSS specialisations is a good thing. This encourages more distributed knowledge sharing.
  • LeSS explicitly priorities feature teams over component teams to maximise the delivery of end to end value. Both have trade-offs.
  • LeSS doesn’t explicitly include technical practices in it’s rules. It assumes organisations adopt modern engineering practices. To quote their website, “Organizational Agility is constrained by Technical Agility.”
  • A lot of LeSS has big implications about organisational design. Agile teams showed how cross-functional teams reduce waste by removing hand-off. LeSS will be even more demanding on organisations and their structure.

LeSS Huge

The creators of LeSS made LeSS Huge because they found a Product Owner was often a constraint. Since Product Owner’s focus on prioritisation, it’s hard to keep an overview and manage the priority of 100+ Backlog Items. (Note that teams still do the clarification, not the Product Owner). With 8+ teams, they found even good Product Owners could not keep on top of the ~100+ refined Backlog Items (which normally covers the next 3+ sprints).

LeSS Huge addresses this by introducing Categories (aka an Area). Each Backlog Item has its own category, and each category then has an Area Product Owner to manage the overview and prioritisation of Backlog Items in that category.

Guidelines for creating an area:

  • This should be purely customer centric
  • Often grouped by stakeholder, or certain processes
  • Could be organised by a certain market or product variant
  • No area in LeSS Huge should have less than 4 teams

Conclusions

After taking the course, I have a much stronger understanding of LeSS’ origins and how it works. After the course, it feels much LeSS complex than when I first read about it on their website. It includes many principles which I run software teams by. I can also see many parallels to what I have done with larger organisations and LeSS. I can also see how LeSS is a challenging framework for many organisations. I would definitely recommend larger product organisations draw inspiration from LeSS. I know I will after this course.

2018 in Review

Reflections on 2018

In 2017, I stopped working as a consultant and started playing the role of CTO in Berlin. I learned a lot moving away from consulting into a full-time management role. I am happy with the direction the technology team and platform is moving, given where it was when I started. You can read more about what we achieved in 2018, and I’m proud to have been a significant part of that.

I expected to travel less as a consultant. Yet that didn’t seem to really work out. Places I visited for both work and leisure included: Barcelona, Munich London, Brussels, Austin, Capetown, Budapest, Vienna, Heiligendamm, Sitges, Zurich, Siegen, New York, Krakow, Oslo, Cadzand, Malmo and Amsterdam.

I still spoke at many conferences and meet ups including: NDC London, OOP Conference, Microservices Munich Meetup, keynoted the inaugural LeadDev Austin, Landing Festival (Berlin), Craft Conference, We Are Developers, CTO Roundtable Berlin meetup, FrontEnd conference, JDD Conf, GoTo Berlin, the inaugural LeadDev Berlin meetup, Øredev and a number of evening meetups for my company across Berlin, New York and Barcelona.

I was still able to post a number of blog entries across the year. I also focused on sharing a lot of research material on twitter. It seems to be very well received or appreciated so far. I also was able to get back into a lot of reading. I’m a big fan of Pocket, perfect for reading when I’m flying or traveling. According to them, I was in the top 1% of readers, getting through the equivalent of about 49 books. I also got into the habit of reading whilst commuting with my Kindle. Between a handful of real books and ebooks, I got through about 40 books.

What did your 2018 look like?

Thanks Jerry Weinberg

If you have worked in IT for some time, you will have come across the name Jerry Weinberg (Gerald M Weinberg). I first came across Jerry when I first read his book, “The Secrets of Consulting.” Jerry impacts great wisdom through his use of stories. He shared his knowledge generously with our industry and set a great example.

He was a prolific writer and I was lucky to inherit many of his books when a contact moved house. I devoured them rapidly, learning much in the process. As a proud Systems Thinker, I enjoyed “An Introduction to General Systems Thinking.” As someone passionate Technical Leadership, I inhaled, “Becoming a Technical Leader.” I refer and recommend many of his books time and time again.

I never had the opportunity to meet Jerry but I met many people who he had personally influenced. I heard amazing things about the “Amplify Your Effective (AYE)” conference. I felt people who frequented the AYE conference came away with more drive to have a greater impact. I regret not taking the one opportunity I had to take part, given the wrong timing and place in my life.

As someone who believes in agile values, I was lucky to meet Norm Kerth. I forgot he co-authored the “Project Retrospectives” book with Jerry Weinberg. Continuous improvement is the basis for better organisations, teams and processes. Call it retrospectives, kaizen or some other name. I count myself lucky for reading this early on in my career.

We stand on the shoulders of giants. Jerry was definitely a giant among giants. In the world of software we often have a negative association with the word, “legacy.” We forget that sometimes that legacy can be a good thing. I am particularly grateful for the legacy Jerry left behind. 

Flavours of Agile

I started programming around the time people published the Agile Manifesto. My manager at the time handed me the first edition of Extreme Programming Explained. I was also lucky to work in an environment where I could see the first hand problems agile set out to solve.

Fast forward many years later and agile is “mainstream.” Others defined new agile methods. I want to use this article to capture my understanding and share my opinion about these methods. This means you may not like what you read. Consider this your warning. 🙂

The original agile methodologies

Scrum

Scrum is today, sadly, synonymous with Agile. Founded by Ken Schwaber (now with Scrum.org) and Jeff Sutherland (now with Scrum Inc). I see this agile methodology as an improved project management process. It brings rhythm and synchronises people all working towards the same goal. I like how Scrum provides a simple starting framework that builds trust through incremental delivery. Plan a bit, deliver a bit, inspect and adapt.

What I don’t like about Scrum is the cult-like behaviour driven by commercialisation. Subscription “certification” for sitting in a class for 2 days anyone? Like all typical corporates, the Scrum Alliance has expanded to offer ~10 certifications. NOTE: Scrum certifications do not (for me) equate to competence or experience

My usefulness rating: 7 out of 10

Extreme Programming (XP)

I’m definitely biased because I started off with this methodology. Invented by Kent Beck, XP builds on Scrum practices and adds in technical practices. Even these technical practices bring value without necessarily following XP. Examples include Continuous Integration, Pair Programming, Refactoring, and Automated Testing including TDD.

I like how XP highlights technical practices that make agile software development work.

My usefulness rating: 9 out of 10

Feature Driven Development (FDD)

In my experience, FDD is not heavily used in the industry. It’s iterative, focuses on domain modelling and used dynamic teams to create features. I like how there is an explicit design phase for features and a focus on unit testing.

In opposition to XP, FDD encourages individual class/feature ownership. I feel this trades-off consistency within a feature against consistency in the application. I used FDD as an inspiration for delegating to Feature Leads.

My usefulness rating: 6 out of 10

Adaptive Software Development (ASD)

ASD stems out of the Rapid Application Development (RAD) methodology. It grew from the work of Jim Highsmith and Sam Bayer. This methodology is super simple. Small cycles of Speculate, Colloborate and Learn.

ASD is not prescriptive with its practices, instead providing guidelines. I like how it highlights Mission, Vision, Leadership and People. This will specifically appeal for those in management roles. It was one of the first books to recognise software as complex adaptive systems.

My usefulness rating: 6 out of 10

Dynamic Systems Development Method (DSDM)

I have never experienced this methodology in the wild. I see DSDM as another project management framework fitting with the spirit of agile. I like the emphasis on modelling and the invention of MoSCow (Must Have, Should Have, Could Have).

I like less that it’s “owned” by a consortium, which limited its adoption to mostly the UK.

My usefulness rating: 3 out of 10

Crystal

Crystal is a meta-methodology. Alistair Cockburn, who thinks deeply about the process of building software, invented Crystal. Crystal is the methodology to help define a specific methodology. Cockburn describes a process to “tune” a methodology to fit its context. Cockburn created specific methods (e.g. Crystal Clear) for different contexts. Some cater to larger groups. Others consider the domain characteristics (e.g. safety or life critical)

Like other agile methodologies, Crystal focuses on collaboration and communication. In his book, I liked how Cockburn described osmotic communication. It was also one of the first methodologies I read that focused on personal safety. Google’s research demonstrated how important psychological safety is for high performing teams.

My usefulness rating: 6 out of 10 (It would rate higher but I scored it less because it’s a meta-methodology)

Second-wave agile methodologies

I refer to the following as second-wave methodologies. They emerged as more people connected with the agile values and community.

Lean Software Development (LSD)

The Poppendiecks created LSD by importing lean manufacturing ideas into software development. LSD focuses more on principles and, to me, feels less concrete compared to other agile methods. I really liked the ideas of value stream mapping and trying to follow and reduce waste.

I was never able to reconcile one mental model. Product discovery is naturally exploratory in nature. Except if you are digitising a manual process. As a result, there is some natural waste in the system that you can’t get away from.

My usefulness rating: 7 out of 10

Kanban

David Anderson created the official “Kanban Method”. He took the Theory of Constraints and applied it to the flow of software development. This method is simple and is a super useful Getting-Things-Done (GTD) technique. I’ve heard of weddings and house moves planned with Kanban boards. I’ve even used one myself for Christmas meal planning.

The method is easy to get started and immediately practical

My usefulness rating: 8 out of 10

Scrumban

Loosely attributed to the evolution of teams as they move from rigid Scrum to Kanban.

My usefulness rating: 7 out of 10

Scaled agile methods

As agile went mainstream, large organisations wanted to “adopt agile at scale.” The result is a plethora of methods that cater for the “enterprise.” I have yet to experience any of these successfully work at creating a truly agile organisation. Many of these feel like rebranding existing dysfunctions as “acceptable agile.”

Scaled Agile Framework (SAFe)

Many leading agilists have written enough about SAFe for you to make up your own mind. I have witnessed a poor enterprise choose to go down the SAFe path. They found it didn’t help them solve many issues. I feel SAFe allows mediocrity. I find it doesn’t put enough emphasis on the continuous improvement. Nor does it emphasise a shift of values (e.g. “People over process”).

I do like that it touches upon topics such as Portfolio Management and Architecture. I don’t think that makes SAFe agile.

My usefulness rating: 2 out of 10

Large Scale Scrum (LeSS)

I know Bas Vodde personally from the retrospective community and I have a lot of respect for him. Bas Vodee and Craig Larman (creators of LeSS) also wrote a book about Scaling Lean & Agile Development. The book acts as a case study from their experiences.

I haven’t personally experienced LeSS. I feel that LeSS is more in the spirit of agile than SAFe. It is a starting framework (the authors say it themselves) about how you might apply Scrum to very large groups. LeSS focuses on 1-8 teams and LeSS Huge focuses on 8+ teams. This is a simple starting framework that organisations might use as a starting point.

I find the LeSS website rather confusing to navigate.

My usefulness rating: 7 out of 10

Scrum@Scale

One of the founders of Scrum (Jeff Sutherland) first published the guide for Scrum@Scale. The guide is free, simple and very Scrum focused. Scrum@Scale doesn’t simply target agile software development, so is very process focused. It doesn’t mention any technical practices that are also needed at scale.

It feels like it tries to keep the agile spirit, by being lightweight, simple and iterative. Scrum@Scale introduces more complex terminology (e.g. Executive Action Team, Executive MetaScrum). I can see how this might help large projects involving lots of people.

My usefulness rating: 5 out of 10

Nexus

Nexus is Scrum.org’s answer to scaling Scrum. Ken Schwaber (the other Scrum founder) defined Nexus. Nexus attempts to create more alignment via its Nexus Integration Team. Nexus also applies many Scrum practices to this central group. Examples include the Nexus Daily Scrum, Nexus Sprint Planning & Review and the Nexus Retrospective.

I like how Nexus reuses many of the Scrum concepts to try to provide consistency with its scaling method. It feels lightweight enough. Nexus aligns with core agile ideas. It focuses on  transparency, iterating and the constant flow of value.

I don’t like how Nexus (like Scrum) fails to include any technical practices.

My usefulness rating: 6 out of 10

Disciplined Agile Delivery (DAD)

The people behind the, IMHO complicated, Rational Unified Process did it again. They invented Disciplined Agile Delivery. DAD appears to define a solution for the entire organisation. This choice adds a lot of complexity to try to address everything.

DAD feels less prescriptive than other scaled methods. It still feels to me overly complex. DAD prescribes no single lifecycle for synchronisation. They even map how other practices map to different lifecycles in their view.

Trying to do too much without being prescriptive? A good starting point but its complexity makes it less accessible.

My usefulness rating: 5 out of 10

Back to basics

Agile started with a simple set of values and principles. Second-wave methodologies connected ideas from other fields to name new practices. When agile crossed the chasm, people tried to “scale” agile and it got excessively complex. Many of these, IMHO, feel like snake-oil. Many focused on selling consulting or training instead of delivering value early. It’s only natural that early agile practitioners tried to bring agile’s core back.

Modern Agile

Joshua Kerievsky invented Modern Agile. The ideas refocus people’s attention away from complex methods. Instead of practices, Modern Agile focuses on four simple principles. It encourages people to be agile instead of simply doing agile. I have a lot of respect for Kerievsky. He is an ideal role model in the agile community. He applies agile values and principles to his company, Industrial Logic. He is also super generous in sharing his knowledge and lessons learned with everyone.

I like how Modern Agile is so simple. I like how accessible they make it and how they’ve built up a strong community that shares generously. The Modern Agile community shows where to start and how to continuously improve.

My usefulness rating: 7 out of 10

Heart of Agile

Alistair Cockburn started the Heart of Agile to, once again, focus on principles. I feel this emerged as a result of of “scaling agile” and including “all the practices.”

I like how the Heart of Agile is a simple set of principles that guides people to think with an agile mindset. It reminds me of the Deming Plan, Do, Check, Act/Adjust (PDCA) cycle of continuous improvement.

My usefulness rating: 7 out of 10

Conclusion

I am amazed at the emergence of new “agile methodologies.” From a positive note, it demonstrates how wide agile has reached. It also demonstrates how the Agile Manifesto did such an effective job. A simple set of statements brought a worldwide community together. It provided an umbrella for people to share ideas, knowledge and practices. Agile catalysed improvements in the state of software development.

This list is my attempt to better understand some of the newer methods. I admit this list will never be complete. It also reflects my own, limited and biased views of the methods above. YMMV.

I wanted to provide a simple overview of what’s out there (as of this writing). I challenge you, the reader, to start small and iterate. In the true agile spirit, pick something that adds immediate value. Improve your situation and continually inspect and adapt. It will never be perfect but you can continuously improve.

Book Review: Accelerate

I first heard about this book when I saw Jez Humble (@jezhumble) keynote at OOP earlier this year. You will get significant value from this book. Jez has already made many contributions to our industry. He introduced Continuous Delivery (CD) and the Lean Enterprise. He also helped shape the field of DevOps, as we know it today.

The Science of DevOps: Accelerate Book

Think about this book as a very readable academic paper, based on the long-running State of DevOps report.

Rigour in its research method

The book describes how the authors gathered vast data and their research methods. They discuss their observations and lead you to their conclusions, with concrete examples. The author shared how some of their assumptions turned out false. An example is the study showing how there is a positive correlation with Trunk-Based Development (TBD) and quality. This technical book is a rare gem based on rigorous research methods. Nicole Forsgren obviously had a large impact on the book

I’m amazed at how rich their raw dataset is. The authors draw on four years of data from many responses around the world. Their sample size towers over many academic studies. Many academics rely on student control groups instead of real industry data. Rarely academics also get to study a few companies or teams within a single company. The wealth of the raw data gives more weight to the report’s authenticity and credibility.

Martin Fowler highlights one point in the Foreword which I agree with. Even though the survey raw data comes from many sources, it is still self-assessed. Self-assessments are naturally biased by Dunning-Kruger effects.

Strong guidance and good advice

Our industry struggles with useful performance measures in IT. Metrics are either irrelevant or drive poor behaviours. This book debunks false prophets like Gartner’s Bi-Modal IT. Spoiler: You can got fast AND have quality, unlike normal assumptions. The book, Accelerate, gives strong suggestions for useful KPI measures. The authors present convincing conclusions that any modern technology firm should take on. This book gives many ideas to improve software and organisational architectures, and processes.

Many studies such as this focus only on the technical practices (such as CD or TBD). Many experience people realise a focus on technical practices is not enough. They realise organisational processes or structures constrain the value technical practices bring. To make the most of technical practices, management must look at their processes and structures. (Disclaimer: We address this topic in our book about Building Evolutionary Architectures). Maybe it’s confirmation bias, but the chapter on Transformational Leadership is super important.

Here’s an simple example why. Imagine you have an organisation with a Head of Development and Head of Operations. Each have hundreds of people with different reporting structures and processes. If the Heads do not support new initiative like DevOps, collaboration won’t move very far.

Conclusion

I found this book extremely easy to digest. I wanted to read more about their research methods. The authors convinced me of their conclusions and made them come to life with concrete examples. I highly recommend this book for any technology executive in the modern world. Accelerate sets the standards for measuring the performance of technology firms in 2018.

Why we wrote Building Evolutionary Architectures

When I first started working as a developer, agile was a taboo-word, seen as a fad driven by developers. Scrum was, at least in Australia, unheard of and I luckily fell into a team experimenting with XP (Extreme Programming) combining CruiseControl with CVS and the first version of JUnit.

In those days, most projects ran using some sort of waterfall process with a lengthy requirements-gathering phase, a long architectural design phase followed by problematic development and often a stressful testing phase. You were lucky to get access to a new development because there were long delays in obtaining new infrastructure, waiting for some operations person to set up the machine, configure the services and grant you access.

Fast forward to today where we have a completely different world of technology. We have rich, open source libraries that give us fundamental building blocks to focus on solving our problems. We have powerful computers with vast disk space, processing capacity and memory that enable us to build complex features without waiting for a lengthy compile or build phase. We have access to cloud services that give us even more compute power, disk space and broadband that allow us to rapidly interact with remote services, almost as if they were on a local network.

Today’s world of building software looks very different from what it looked ten or fifteen years ago. The way that we need to design and architect our systems also needs to change. This is one of the reasons why my co-authors and I decided to write the book, “Building Evolutionary Architectures

Long phases of designing an architecture will likely result in an architecture that will be cumbersome to build. Zero architectural design will fail to meet what we deem as a software’s “fitness function.” Instead, developers need to consider how their systems will adapt to change and we’ve looked at modern software development practices, methodologies and processes to understand what supports change and, more importantly, what typically hinders change.

If you’re interested more in this topic, then check out this page on how you can learn more about building evolutionary architectures.

Quotes on metrics and numbers

I published an article a few years ago, called “An Appropriate Use of Metrics.Martin Fowler, who hosts the article, tells me that it receives good regular readership. As someone who has been working as a consultant, I’m aware of how an inappropriate use of metrics can really incentivise the wrong behaviour, destroy company and team cultures and drive incongruent behaviours between teams and people.


Source: From Flickr under the Creative Commons licence.

In this post, I thought it’d be worth sharing a few quotes around numbers and metrics. I’ll leave you to decide where they may or may not be useful for you.

Tell me how you measure me, and I will tell you how I will behave.

Source: Eliyahu M. Goldratt (Father of the Theory of Constraints) from “The Haystack Syndrome” (1980).

What can be counted doesn’t always count, and not everything that counts can be counted.

Source: Often attributed to Einstein but the Quote Investigator suggests crediting William Bruce Cameron (1963).

Not all that matters can be measured.

Commentary: An alternative form to that above often attributed to Einstein.

What gets measured gets done, or What gets measured gets managed.

Source: According to this blog, there doesn’t seem to be a definitive source.

It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.

Source: W. Edwards Deming from “The New Economics.”

(One of the Seven Deadly Diseases of Western Management) Management by use only of visible figures, with little or no consideration of figures that are unknown or unknowable.

Source: From W. Edwards Deming’s Seven Deadly Diseases of Western Management.

Data (measuring a system) can be improved by 1) distorting the system 2) distorting the data or 3) improving the system (which tends to be more difficult though likely what is desired).

Source: Brian Joiner via the article, “Dangers of Forgetting the Proxy Nature of Data.

The most important figures that one needs for management are unknown or unknowable.

Source: Lloyd Nelson (Director of statistical methods for the Nashua corporation) via Deming’s book, “Out of the Crisis.”

When a measure becomes a target, it ceases to be a good measure.

Source: Also known as Goodhart’s Law phrased by Marilyn Strathern.

If you can’t measure it, you’d better manage it.

Source: Management consultant, Henry Mintzberg

People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.

Source: W. Edwards Deming. No concrete source found except for Brainyquote.

« Older posts

© 2024 patkua@work

Theme by Anders NorenUp ↑