patkua@work

The intersection of technology and leadership

Category: Agile (page 1 of 22)

Thanks Jerry Weinberg

August 11, 2018 / / 0 Comments

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 Diagram in Ice Cream form

Which flavour do you prefer?

Flavours of Agile

July 14, 2018 / / 1 Comment

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: 5 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

May 27, 2018 / / 0 Comments

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

November 26, 2017 / / 0 Comments

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

November 5, 2017 / / 3 Comments

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.

Just Published: Building Evolutionary Architectures

October 9, 2017 / / 3 Comments

I’m very proud to announce the release of a new book that I co-authored with Neal Ford and Rebecca Parsons whilst I was at ThoughtWorks. Martin Fowler writes the Foreword (snippet below):

While I’m sure we have much to learn about doing software architecture in an evolutionary style, this book marks an essential road map on the current state of understanding

Building Evolutionary Architectures

It marks the end of a very long project that I hope will have a positive impact on the way that developers and architects consider building and designing software. We will also post related news to our accompanying website evolutionaryarchitecture.com

You can find the book available on:

Enjoy!

Starting as CTO at N26

September 18, 2017 / / Comments Off on Starting as CTO at N26

I’m excited to announce that I’ll be taking on the Chief Technology Officer (CTO) role for N26 (formerly Number26), Europe’s first mobile bank with a full European banking license, and who is setting new standards in banking.

I’m joining an exciting and talented team based in Berlin, Germany – one of the favourite start-up cities in Europe. In my new role, I’ll draw upon more than a decade of my consulting experiences with the well-respected and industry-changing technology firm, ThoughtWorks – best known for leading the adoption of agile ways of working (particularly its technical practices), publishing open-source software like CruiseControl (the first widely used Continuous Integration servers) and Selenium (well-known automated web-testing tools), and sharing ideas through books like Continuous Delivery and the Lean Enterprise. I’m really looking forward to applying my experiences guiding organisational design, building evolutionary architectures, developing technical leaders all while sustainably delivering value for our customers.

What will be different?

After many years as a consultant, I realise that working with a product organisation is a different beast. I look forward to having some responsibility to instigate and guide changes throughout the organisation and living out the long-term consequences (both good and bad!) of my actions. I know that this is often a missing feedback loop for consulting. In my role, I’ll be able to invest more in challenging and growing people and building out new technical and organisational capabilities.

I also look forward to spending a bit more time “at home”. I still expect to travel for my new role, still speak at some conferences but I hope I will have a bit more say as to when and where I’ll travel to, based on our business needs rather than where clients happen to be based. Did I mention that I’ll also be based in Berlin, and it’s a great city with a very good balanced lifestyle? I might even get a chance to further develop my German again.

Why FinTech and N26?

As a consultant, I was always skeptical about having significant long-term impact on established financial companies. With teams, or parts or the organisations, yes. With a 10,000+ person company, less so. The exciting part about working with N26 is that I will work with a strong management team to prevent unnecessary bureaucracy and to let people focus on adding value to the product and organisation. We benefit from not supporting certain types of legacy, and building software with Continuous Delivery and modern technologies first. I’ll be helping guide us away from the traps and pitfalls I have seen many customers suffer from in the last decade.

The N26 Black Card

I also like the fact that N26 is growing fast, and has already proven to meet customer needs, where all growth has been organic so far with very little advertising. Did you know that we recently hit 500,000 customers (PDF)? It’s also one of the first mobile-first startup banks with a European banking licence, which opens up a world of opportunity that a lot of other FinTech banking products do not yet have.

Here’s what TechCrunch wrote two years ago:

N26 (Number26) could be the best banking experience in europe – Tech Crunch

Bank of the future

In case you can’t tell, I’m really delighted to be leading the technology organisation behind the bank of the future. The team has already accomplished a lot so far, and I look forward to working with the team to do even more. We’re going to build an exciting place to work in the FinTech sector and have a huge impact on our ever-growing customer base across Europe. If you’d like to be a part of the N26 team and join me on this journey, did I mention that we are hiring?

Drop me a line on twitter @patkua (DM’s open), or on my email address if you’re even curious. Berlin’s a great city to live and N26 is a great place to work while you’re there.

The Technology Landscape in Singapore

June 29, 2017 / / 0 Comments

Earlier this year, I held my Tech Lead Skills for Developers workshop in Singapore and Thailand. It was a short and busy week including some customer visits and a talk on Building Evolutionary Architectures for the local community.

As a consultant, I’m lucky to travel to different parts of the world where I have been able to compare technology industries and cultures around the world. Please note that the following observations are simply my observations and not necessarily backed by research.

Extreme Shortage of Developers

Talking to a number of managers, it’s apparently very difficult to find experienced and very good developers. There seem to be a number of reasons for this including how Singapore Universities aren’t producing enough software developers, a country limit that ensures a consistent ratio of foreign and local talent and a culture that values higher status over getting things done.

Dense and active community

Singapore reminds me a lot like London. The financial sector has a big impact on the technology market. London is much more diverse from that perspective. Singapore, like London, is a small dense population with a very good public transportation network. The public infrastructure enables many community meetups as people don’t have to worry about driving, traffic or how long the commute might take and thus enables a lot of learning to be done.

One of people I met during my time at Singapore, Michael Cheng (or @coderkungfu), organises the Engineers.SG website, where they go around to meet ups, film the talks and put them online.

Above is a picture of Michael and I during the course I was running. What he organises is no small time-commitment, and is a huge service to the community and makes the content available to a much wider group.

High Power Distance Index (PDI) matters

Accroding to Hofsted, a researcher on the cultural dimensions of countries, Singapore has one of the highest PDI ratings. This means that ranking, titles and the relationship between titles matter more to people in Singapore than in countries with a lower PDI (such as the US or the UK).

Translated into the local market – almost everyone wants to be a manager.

One person was telling me about one team where they had two developers building software and eight managers managing! It wasn’t of any surprise to me that this team worked in a finance industry. It also didn’t surprise me that not a lot of work got done!

Singapore is following, not yet leading in technology

Singapore is known for its passion and drive to make a big difference for its size. I see many great things changing on the island state, however I see many other challenges in their market that simply investing in programmes as a nation won’t necessarily change.

If you want any other perspectives on this market, I’d recommend reading a couple of this articles:

Three ways to handle CFRs image

Three ways to handle CFRs

Three ways to handle CFRs

May 28, 2017 / / 0 Comments

Cross-Functional Requirements (CFRs) are some of the key system characteristics that are important to design and account for. Internally we refer to these as CFRs, although classically they might be called Non-Functional Requirements (NFRs) or System Quality Attributes, however their cross-cutting nature means you always need to consider the impact of CFRs on new or existing functionality.

In the Tech Lead courses that I run, we discuss how it’s important that the Tech Lead ensures that the relevant CFRs are identified and accounted for either in design or development. Here are three ways I have seen some CFRs accounted handled.

1. CFRs satisfied via user stories and acceptance criteria

Security, authentication and authorisation stories are CFRs that naturally lend themselves to actually building out testable functionality. It’s important to consider the effort the risk and, in my experience, is important to start implementing these early to make sure they meet the needs and can evolve.

For these sorts of CFRs, it’s useful to identify these as natural user stories, and once implemented become acceptance criteria on future user stories that touch that area of the system.

As as example, authorisation can be dealt with by introducing a new persona role and what they might do (or not do) that others can have:

As an administrator, I would like to change the email server settings via a user interface, so that I do not need to raise an IT change request for it.

If this is the first time that this user story is implemented, then some acceptance criteria might look like:

  • Only a user with an administrator role can access this page
  • Only a user with an administrator role can successfully update the email setting (check the API)
  • Users with no administrator access receive a 403 or equivalent

This new role addition often means considering new acceptance criteria for every story going forward (if it should be accessible only by administrators or by all.

2. CFRs satisfied through architectural design

Scalability and durability are often CFRs that require upfront thinking about the architectural design, and perhaps planning for redundancy in the form of additional hardware, network, or bandwidth capacity. A web-based solution that needs to be scalable might draw upon the 12-factor application principles, as well as considering the underlying hardware. Failing to think about the architectural patterns that enable scalability and start coding will lead to additional rework later, or make it even impossible to scale.

3. CFRs satisfied via the development process

User experience is a CFR which often requires people, making automated testing much more difficult. An application where a high level of user experience is best dealt with by ensuring that a person with a background in UX is involved and that certain activities and feedback cycles are planned into the software development process to continually fine-tune the user experience as an application evolves.

Changes to the development process might include explicit user research activities, continuous user testing activities, the addition of an A/B capability and some training for product people and the development team to ensure that the developed software meets the desired level of user experience.

Conclusion

Every system has their own set of Cross-Functional Requirements (CFRs) and it is essential that teams focus on identifying the relevant and important CFRs and find ways to ensure they are met. In this article, I shared three typical ways that CFRs might be met.

How else have you seen these handled?

Feedback Booklet

The Gift of Feedback (in a Booklet)

March 19, 2017 / / 0 Comments

Receiving timely relevant feedback is an important element of how people grow. Sports coaches do not wait until the new year starts to start giving feedback to sportspeople, so why should people working in organisations wait until their annual review to receive feedback? Leaders are responsible for creating the right atmosphere for feedback, and to ensure that individuals receive useful feedback that helps them amplify their effectiveness.

I have given many talks on the topic and written a number of articles on this topic to help you.

However today, I want to share some brilliant work from some colleagues of mine, Karen Willis and Sara Michelazzo (@saramichelazzo) who have put together a printable guide to help people collect feedback and to help structure witting effective feedback for others.

Feedback Booklet

The booklet is intended to be printed in an A4 format, and I personally love the hand-drawn style. You can download the current version of the booklet here. Use this booklet to collect effective feedback more often, and share this booklet to help others benefit too.

Older posts

© 2018 patkua@work

Theme by Anders Noren — Up ↑