Agile Culture Capability Model: Looking for the Primary Soft-Skills Set of an Agile Team Member

One of the most exiting topics I’m working on is the Agile Culture Capability Model (ACCM), which should finally help us to judge about human capability to be agile, and what can be done to improve it. I don’t want to go in to details here; I hope I will write an independent, comprehensive post about it soon.

However one of the dimensions I use in the ACCM, are the soft/behavioral-skills every member of an agile team should have. Based on my experience and resources I had analyzed, I have created the first version of such Primary Soft-Skills Set (naming conventions and order not relevant):
  • Communication/Collaboration
  • Time Management/Planning
  • Thinking/Learning/Problem Solving
  • Conflict Management/Handling stress
  • Dealing with Change/Flexibility
  • Decision making/Commitment
  • Goal oriented/Value driven
  • Teamwork/Teambuilding
  • Leadership/Diplomacy/Facilitation
The question is, is it comprehensive enough? What is your opinion? Many thanks in advance.

Second Step to Heaven: Scope Simplification using Partition Refactoring and Partition Reduction

In the first part of this blog series I have discussed how to use SIP process ideas (Simple Iterative Partitions created by Roger Sessions) to define the scope of a system to be built, using clear defined partitions, epics and agile-enabled user stories (AEUS).

However we can still run some actions to make the system to be simpler by making it compliant to the laws of simplification. Once again I will reuse definitions and terminologies defined by Roger and adjust them to suit my needs.

Let’s look at the adjusted First Law of Simplification:
Subclasses of a partition should be constructed with the synergistic equivalence relation. From an agile-enabled user stories perspective, this means that an epic should be further decomposed, if possible, so that functionality is distributed across lower level epics by synergy. In other words, by placing together functionality that is logically inseparable.

How to achieve this goal? First of all you have to check if all your user stories are Minimum Marketable Features (MMF). According to the definition I found in the “Software by Numbers” by M. Denne and J. Cleland-Huang (Prentice Hall, 2003), a MMF, as the name implies, is characterized by the three attributes: minimum, marketable, and feature. The ideal MMF is a small, self-contained feature that can be developed quickly and that delivers significant value to the user. So your task is to identify the minimum or smallest possible group of features that deliver significant value to the user.

Secondly you can check if your agile-enabled user stories are compliant to some well-know software design principles like Separation of Concerns and Single Responsibility Principle. All these principles use the simplification as a foundation for their definitions.

I call this sub-step partition refactoring or, as proposed by Roger, continuous partitioning.

The Second Law of Simplification, which was also adapted a little bit by me, states:
Any functionality that can be removed from a partition or epics should be removed.

It is important to understand at which level you are allowed to remove functionality. You should, if possible, remove epics as a whole (if all user stories are dispensable) from a partition or user stories from epics. However you should avoid the removal of functionality direct from the user stories because you can change their context, thus breaking some of the partitioning laws.

Which user stories are candidates for the removal? Let’s look at them here:
· Remove user stories with so called “maybe we will need it” functionality. “Maybe” is out of scope.
· Remove user stories with solely horizontal (boilerplate) functionality. As stated in my previous posts, an agile-enabled user story is business oriented.
· Remove user stories that explain “how”. Leave only “what” user stories.
· Remove all non-ideal MMFs, as defined above.

This second sub-step I call partition reduction.

Both partition refactoring and partition reduction are core elements of the scope simplification.

So, two steps are done: partitioning and simplification. The next, third step on the road to to heaven is the prioritization.


Agile-Enabled User Stories are Also Business Cases

As I stated here the agile-enabled user stories (AEUS) have to be business oriented. So any user story, when comparing it to the classic architectural layers of a system, is a column or better, a thread. A thread, that runs from the top to the bottom of a system. A business thread.

This led me to the conclusion, that in case of agile-enabled user stories we cannot just define an agile-enabled user story in the context of system's requirements only. These requirements that belong to the well-known four views on the IT architecture (functional, development, deployment and quality views) represent simply just one of the two AEUS definition dimensions. The first one is the requirement dimension that defines what should be build, and is a standard and known by everyone. However there is a second definition dimension named the business case dimension. This definition dimension consist of many subcategories, answering additional questions about an AEUS like why, how, who etc. Here a short list of these subcategories, based on a classic business case template I have found here www.bis.gov.uk/files/file42721.doc:
  • Background - describe the agile-enabled user story.  Why it should be done now and what are the implications of not doing it.
  • Scope - what the scope of the user story is, its key objectives, deliverables and purpose. 
  • Objectives - what you want the user story to achieve when it has been completed. Your objectives should be SMART - specific, measurable, achievable, relevant and timely. Avoid words like improve, optimize, clarify, help etc. These are vague words that mean, you cannot estimate such AEUS and you cannot measure your result.
  • Options - describe and evaluate the different options and give reasons why the preferred option was chosen, including the 'Do nothing' option.
  • Proposed Solution - Identify the selected option and how you propose to implement the AEUS. 
  • Benefits - Summarize the main benefits and how will they be realized. For an AEUS the focus lies in elimination of waste (lean).
  • Risks - identify the key risks that might impact on the user story and the achievement of desired benefits. 
  • Dependencies - are there any user stories that are either dependent on the outcome of this user story or that the user story will depend on.
  • Affordability - What resource will be required, including staff resources and where will this resource come from?
  • Analysis of costs - estimate the user story. You can use a method you like i.e. direct or proxy estimating.
  • Critical success factors - outline the things that must go right to ensure the success of the user story. It can be combined with the risks section.
  • Procurement procedures - explain your proposed procurement route (if applicable).
It seems the idea introduces an overhead, but I think it's even good and in some cases enough to keep this business case dimension just only in mind, when defining and planning the agile-enabled user stories. You will see how great the result will be… on time, in budget etc


First Step to Heaven: Agility of Inception, Partitioning of Epics, Creating Agile-enabled User Stories

The definition of heaven is quite simple: on time, in budget, in quality, and in scope. The road to heaven is quite complicated, we know that. Happily there are a lot of patterns and practices that slowly covers more and more software engineering disciplines, making the challenge manageable. We know how to document user stories, how to estimate them, how to prioritize them, how to implement, test, and roll-out them. In case of user stories we know even how to split them. Look at this interesting Richard Lawrence’s proposal Patterns for Splitting User Stories about various patterns that can be involved in splitting (however I don’t agree with the reasonability of some them).
We even know what the user stories should be: they should be INVEST. But we still don’t know how to start to write them to make them simply agile-enabled! Agile-enabled hmm, what’s that? Just think in the categories that a user story is THE starting point for all project activities I have described shortly above: estimating, prioritizing, implementing, testing etc. So, user stories that are agile-enabled have the following characteristics, they are:
  • Simple in topic (but not trivial)
  • Similar in shape (same size)
  • Universal (supporting role-less teams)
  • Self-contained (no additional explanation needed)
  • Dispatch-able (to the teams and member)
  • Manageable (supporting easy task specification and estimation)
  • Reasonable (hmm, “human-able”)

I have read this year an ingenious book written by Roger Sessions about enterprise architectures, how to create them and how to reduce their complexity (Simple Architectures for Complex Enterprises, MS Press 2008) and how to use the simple iterative partitions (SIP) process. And I have suddenly recognized, as one of the conclusions I had, that the proposed by Roger methods and tools can be adopted to use them as the foundation for creating agile-enabled user stories!

However, above all, the agile-enabled user stories have to be business oriented. First, only such user stories can be understood by the business guys (clear ;) and only such user stories can guarantee a good quality delivered by the development, because the dev guys have to understand what and why they build. Second, agile is about learning and agile is about communicating. How to write a user story that will support learning and communication? Yes, a user story has to be understood by all parties involved; equals business oriented. So, forget any other ideas like e.g. technical user stories (they are simply not partitionable, but about it, in a moment ). However, don’t worry, the cross-cut concern technical functionality like persistence layers, aspects, logging etc. will be extracted and make reusable throughout the refactoring of exiting components within future phases of the project.

To create agile-enabled user stories I propose to use mathematical partitioning and its laws. You should use it as an element of the agile orientation system (agile culture), means as a one of the agile culture standards you would like to have within your organization.

According to the definitions used by Roger, a partition is a set of subsets that divide up some universe such that every element in the original universe ends up in one and only one of the subsets . What? Oh, come on, we use this way of grouping functionality since years starting with domain driven design etc. In every organization you will learn about domains like Customer, Order, Billing, Contract etc. If you look at any software system that supports business you can recognize some basic “functional columns” named domains. They can make up our partitions (for the start).

So let’s look at the Five Laws of Partitions. I will use here Roger’s definitions adjusted by me for the purpose of creating agile-enabled user stories:

First Law of Partitions: partitions must be true partitions in the mathematical sense. For agile-enabled user stories, this means that the functionality must be broken up into a set of subsets such that every function ends up residing in one and only one of the subsets. In case of our agile-enabled user stories these subsets are called epics (yeah, I know you knew :).

Second Law of Partitions: partition definitions must be appropriate to the problem at hand. For agile-enabled user stories, this means that an epic must contain user stories that are closely related to each other. This means that functionality must be assigned to the epic based on the equivalence relation synergistic. Any two user stories are synergistic if the functionalities defined by them are functionally related to each other (I know, it sounds a little bit unclear).

Third Law of Partitions: the numbers of epics in a partition must be appropriate. For agile-enabled user stories, this means that the number of epics that make up a given partition should be in the range of 3 through 10.

Fourth Law of Partitions: the size of the epics in a partition must be roughly equal. For agile-enabled user stories, this means that you don’t want to end up with large differences between the amount of functionality in the different epics of the partition.

Fifth Law of Partitions: the interactions between subsets in the partitions must be minimal and well defined. In practice, this means that you might have to define more than one user story to support functional interfacing.

By applying these laws you can build perfect agile-enabled user stories. But it is the first step to heaven. The second step is the simplification. However it is a topic for another post.


In Quest for Simplicity

Last week I finished to read an ingenious book about enterprise architectures and simplicity challenges by Roger Sessions (“Simple Architectures for Complex Enterprises”, Microsoft Press, 2008). I should write a short review of it just to keep the main ideas stored at one place (hopefully I will find time for this) but there is one short chapter that I don’t want to let it wait… “A Philosophy of Simplicity”.

Here the core sentences that in my opinion don’t need any additional explanation. I can only say, just open your eyes and especially your architecture mind, rethink all you do and act:
- “In reality it is not systems that are getting more complex but system requirements that are getting more complex”
- “The job of the enterprise architect is to design simple systems that do complex things”
- “The paradox about complexity is that it is simple to make systems complex; it is complex to make systems simple”
- “Architectures naturally seek the maximum possible level of complexity all on their own”
- “The observation that architectures are naturally attracted to complexity is actually predicted by physics, in particular, the law of entropy”
- “The law of entropy tells us that the battle for simplicity is never over. It requires a constant influx of energy to keep enterprise systems simple”
- “The enterprise architect should have a passion for simplicity”

I was really I little bit “shocked” I had read this (positive of course). It is more or less an extract of all my findings and conclusions I have collected during my last project years in area of enterprise and solution architectures. Especially the topic of entropy (and the whole area of thermodynamics behind it) has an immense influence on the way we, humans act, thus do architecture, conduct project management etc. I have thought about involving of entropy into process of creating and reviewing architectures for many years already. Assuming our life is also some kind of a project (an individual, time-boxed goal) we are confronted with the laws of entropy every minute of our existence. If you accept this, it is then easier to understand others (humans and systems) and how to stay compliant to “the philosophy of simplicity”.

An interesting example of this never-ending confrontation with the growing entropy I was able to observe during my latest presentation of my current project. The whole project was setup based on “my laws of simplicity” that are same as Roger Sessions, described in his book and they are also based on well known lean principles (especially “waste elimination”). I’m really proud of my system that can do complex things but the core idea and the way of implementing it was simple. So during my presentation the words “simple, simplicity” have been shown and underlined more than once. Paradoxically this “flood of simplicity” has caused a lot of confusion. My colleagues have almost asked “how can you sell it as expensive, when it is simple?”, “simple means trivial?”, “why did you do that, instead of taking something ready, which is more complex, means has more value?” and so on…

As you can see, it is a never-ending task for us “in quest for simplicity helping others in quest of simplicity”. That’s our destiny, cool.


QCon London 2011 Talk Review „Complexity vs. Lean“ by Jurgen Appelo

I have decided to write some reviews about keynotes and talks I attended to and found excellent and important for our IT-world. These reviews are based on my memories and notices only. They of course represent my personal view on the topics and most probably are not 100% compliant with the intentions of the speakers :).

So let’s start with the first one: “Complexity vs. Lean” provided by Jurgen Appelo.

It was early afternoon on Thursday 10th, 2011 as I decided going back to Elizabeth Windsor Room and continue hearing talks from the “Lean and Kanban: Learning Through Systems Thinking” track. Until now I have missed something new and fresh, something with the kick. Most sessions I had heard before were filled out with the “well-known” information about Agile, Lean, Kanban etc. packed in a new “presentation” paper. However, based on the title “Complexity vs. Lean” I hadn’t expected anything new, though… but I was wrong.

Jurgen’s talk was split in two parts. The first part was aimed to explain what “complexity” and “complexity thinking” is. Jurgen gave an overview about different theories that were and are important for the IT world and actually for the whole human being. He talked shortly about the “General System Theory”, “Cybernetic”, “Dynamic Systems Theory”, “Game Theory”, “Chaos Theory” etc. and even the “Evolution Theory”. As far as I understood, his “Complex Systems Theory” is strongly descriptive-oriented and based on the collection of other theories, in contrast to the lean software development, which is rather prescriptive means describing “what to do”, not “what it is”.

Further on, he discussed what the complexity is (difficult to predict) and the problems with the ambiguous definitions of the “simple”, “complicated”, “complex” and “chaotic” systems. He presented his own system classification matrix with three columns titled “ordered”, “complex”, “chaos” (in case of predictability) and two rows titled “simple”, “complicated” (in case of understandability). Additionally he pointed out the importance of so called “black swans” means unpredictable big events (like 9/11 or the current situation in Japan after the earthquake and tsunami). This part of the talk was really great. To conclude it Jurgen discussed his “Management 3.0 Model named Martie” (a management monster) with six views named “Energize People”, “Empower Teams”, “Align Constraints”, “Develop Competence”, “Grow Structure” and “Improve Everything”. I’ve already ordered his new book “Management 3.0” to learn more. It was fresh and innovative.

During the second part Jurgen took the principles of Lean (seven) and Kanban (five) on the board and tried to negate them using his very good rhetoric skills. Some of them I found very noticeable (don’t eliminate waste just to eliminate it, if the cost of the waste maintenance is low or the problem with multi-workflow visualization in Kanban), some of them were not as obvious (like the interpretation of the “see the whole” principle of lean as “optimize the whole”). Jurgen pointed out that the root-cause analysis might not be suitable if there is no cause. Cool. He discussed also the problem of observing and optimizing the system from its outside (as defined by the systems thinking), what is in his opinion wrong and should be done from the inside of the system. Another great topic was the idea to “support” kaizen (continuous improvement) with kaikaku (radical change) to jump out from the local optimization (thus actually executing tasks based on the negated “see the whole” principle ;).

Yeah, that was great talk that moved some of my agile “points of view” out of the paralyzed zone. My head is now full of new ideas. I just have to implement them; thanks Jurgen.


QCon in London: What I've Seen and The Grades

I've just collected the summary of the keynotes and talks I had seen in London during QCon.

I hope I will get some time to write a comprehensive review but here the overview and the grades. Actually most talks were good, some excellent and just one was a crap (scale 1-excellent - 4-crap):



Native Agile and Agile Immigrants

As we all know the first statement from the agile manifesto says “individuals and interactions over processes and tool”. The individuals and interactions play the core role if you want to be agile, clear. However these individuals and interactions are dramatically changing nowadays. Luckily I can now observe in my projects the first native digital generation being mature already (they are all about 30) and the style they work and communicate. Native digitals are socialized with getting feedback fast, with fast information processing, working in parallel and asynchronous, and as a cause with the fast success or failure. "Think big, act small, fail fast; learn rapidly" is the famous pitch out of the book Lean Software Development of Mary and Tom Poppendieck.

These guys have agility in blood, they are native agile.

In contrast I can observe the growing community of the agile immigrants. Similar to the cargo cult they attend to courses and earn such titles as certified ScrumMaster and so on. They offer agility as a product. However you cannot become agile within one week. You are not agile because you run iterations or execute daily meetings. To be agile you have to switch the set of paradigms your life is based on. And it is very difficult or even impossible for the pure agile immigrants.

If you are such an agile immigrant, just hire some native digitals and try to observe them. Give them some basic information about agile principles and start an agile project. It won’t be for sure 100% successful. However you and they will learn a lot. The agile culture will evolve. That is the one and only way to grow to be agile.