Lion van Koppenhagen

About

About this site
This blog — sometimes known as my "Braindump" — is my platform for experimentation and community interaction. It is a way of offloading thoughts.

Isn’t it time to move from hindsight to insights?

In the era of the smartwatch we find it normal to know about ourselves with literally a flick of the wrist, we call it quantified self. Isn’t it time to really move towards the quantified organization, to Fitbit your organization?

Buzzwords

We read about big data, data driven decision making and business intelligence everywhere, buzzwords enough, but when it comes to reality we only use it in hindsight.

These days, if I walk into an office, I get an immediate answer when I ask a manager about sleeping patterns or heart rate. However, if I ask about the performance of the main value streams or delays in those value streams, I’m usually directed to the BI-team. If I ask an SMB owner about cash flow, I’m directed to his accountant. Maybe you feel comfortable driving your car without a realtime dashboard but you shouldn’t and the same goes for managing your organization big or small.

Insights, the path to success

When driving you usually at least watch the speedometer on your dashboard, you don’t go to the garage to ask at what speed you have been driving. Why should managing an organization be any different?

While sometimes it’s okay to follow your instincts, the vast majority of your business-based decisions should be backed by metrics, facts, or figures related to your goals.
By leveraging the wealth of data available into insights, it’s possible to make more informed decisions that will lead to commercial growth, evolution, and an increased bottom line. Those insights should be available in now, not later. What’s holding us back?

Scattered data, high complexity

We have so much data but it’s scattered in silos, or using it is to complex, or our IT organization expects us to use BI-Tools when all we want is insights.

About 10 years ago I was asked to come and drink a cup of coffee at a multi-national sales organization. The sales people where send on a Microsoft training SQL Server Reporting Services so they could create the insights they needed themselves. Imagine the panic. I was asked if we could design a simple solution, we could and we did and it became the most used unofficial application in the company.

So how did we do it and how can you do it?

Land and expand

We followed a simple agile path. Think Big start Small. Always keep the big picture in mind but build for immediate use. We didn’t start off building a complete solution. We build simple blocks named in the language of the users that allowed them to correlate data from various sources into reports, without the need to know the source or how to get there. The salesforce decided which next block would add the most value. All reports were based on data in near real time.

You can do the same for/with your organization. By implementing the right reporting tools block by block, you will be able to make the kind of data driven decisions that will drive your organization forward. It isn’t hard and it should not be costly. Just do it!

This article is an introduction to a series of articles themed telemetry by design. I will post more on my site lion.nu, follow me on linkedin or facebook if you like to read more.

“We had started to make fire trucks that look like spaceships, building systems that no customer could truly appreciate. We had to clean that up.”

Mads Nipper

For some reason I always look at Lego for inspiration when I need to give structure to what goes on in my mind. For me this quote summarises the perpetual tendency to deform simple, elegant solutions into useless monstrosities, spending millions along the way.

I started developing software on a ZX Spectrum and no matter the years of management and consulting, that mindset of a developer is how I look at the world. The list of frameworks I have endured over the years is endless and what they all have in common, is the hours spent by organizations and teams not delivering value. Even worse, the frameworks have become resource hogs, draining organizations of time and money in the attempt to improve. So what’s the problem?

Frameworks, the imposed approach

Regardless whether the framework is called SDM, Prince2 or one of the current frameworks such as SAFe or DAD, they are pitched to the organization and imposed on the teams. Leadership has had little training and consultants are brought in to achieve a lightning change into product and software development. And then there is the failure to achieve the goals of the change. Why?

The framework became the goal

In the rush to improve organizations to achieve their goals more efficiently, the frameworks tend to become the holy grail. Process and procedures are forced upon teams and control mechanisms are put in place to provide management with progress overviews. Failure to meet targets leads to changing the consultants, changing the framework or both and to no avail. Why?

Failure to address culture

Culture, the hardest component of an organization to change. It is not the framework or methodology that makes a team successful. It is the culture and mindset in the organization that leads to success. Change needs to come from culture and a mindset, not a framework. So where do frameworks fit?

The use(fulness) of frameworks

Changing culture and mindset takes time, it also needs tangible tools to help you on the way. Following the ShuHaRi concept, frameworks can be useful as a tool in the journey of change. The most valuable element in change, being lessons learned or retrospectives, can be found in any modern framework. Use frameworks wisely, use them to support the change you wish to achieve but beware, don’t let using the framework become the goal.

If you would like to know more or need help, feel free to reach out.

Read More

For those interested in flow, another oriental way of thinking might also be good to read up on.

Shu-Ha-Ri.

Shu – In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.

Ha – At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.

Ri – Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

Applied to yourself it helps you recognise how Agile you are, applied to others, It helps you coach them in their maturity drive at the right level.

Working in the development industry and experiencing changes in the way of working first hand, led me to writing this article. Regardless of paradigms, the goal is to develop working solutions for internal/external customers in a timely cost efficient manner. This perspective is especially important for scrum masters to understand their role. 

In many teachings the focus of the role of a scrum master is primarily defined as guiding the team(s) through the rituals of the chosen framework in a rigid process focused manner. This narrow focus is more often than not becoming its own impediment.

Being adaptive and agile means being able to change decisions all through the pipeline by iterating back and forth between the people who have responsibility for delivery and those who are responsible for understanding the marketplace. If we want business agility we need innovations of every size to flow through the organisation’s delivery pipeline without being blocked by gates, bad interaction or poor project management techniques. The paradigms and frameworks are there to serve organisations achieving the mindset and having a blueprint to deliver value.

From this we can derive the real role of the scrum master. The scrum master is the facilitator, responsible for managing the flow. The scrum master should focus on culture and interaction as well as a few guidelines. The scrum master uses the framework and tools to power an intense level of social interaction and a decisions flow from good interaction at work. 

The scrum master is the flow master. The scrum master evaluates where he can be of service to make sure we have a predictable continuous flow in the delivery of working solutions. This adheres completely to the principles of original agile manifesto:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

Organisations need to recognise this in order for any agile transformation to succeed.

If you would like to know more about flow or need help in exercises to improve flow, feel free to reach out.

After successfully completing the course at Digital Delta, I can conclude it is almost the same as the role of the scrum master. The only difference is the domain specific knowledge the architect shares (not dictates) with the teams but:

Emergent Design

Ideally, Agile Development Teams are supposed to have the mandate to decide how and what to improve on the architecture. As features develop by order of highest demand, so each team should grow the architecture needed to support them. This is paraphrased under the concept of ‘emergent design’, and it follows from Agile principle number 11.

Complexity brings risk

That is fine for the low complexity of a start-up. In a scaled environment however, with many teams developing products at the same time, whose products are getting more and more complex, with several layers of communication within and externally, extracting data from many different sources… emergent design is a recipe for instability at the structural level. It isn’t enough to just ‘KISS’, because

“For every complex problem there is an answer that is clear, simple and wrong” Henry Mencken

So how do we define architecture in a complex context? To simplify isn’t even always a possibility, the same way as downscaling isn’t always the right thing to do. Instead, we have to work with complexity and try to organize as much as possible. One possible answer for that is the Intentional Architecture as designed and executed by the architects at the System, Solution and Enterprise levels.

An intentional frame for emergent details

Whether you’re a System, a Solution or an Enterprise Architect in a Lean-Agile enterprise, you are in charge of providing a strategy and vision to improve the architecture incrementally, leaving enough room for a coordinated emergent design effort brought on by the development teams. You provide the powerful and coordinated base for Agile teams to keep focusing on delivering value to end customers. It’s up to you to build the right amount of architecture that will enable this value to be implemented and potentially delivered.

You have a responsibility to help teams coordinate, define and share information at the appropriate levels; to understand the underlying purpose and also to be influential enough to direct the fitting amount of funding to the technical aspects and evolutions, to ensure it will get done.

The key is in the balancing act

Balancing sensibly between intentional architecture and emergent design, supported by techniques such as Model-Based Systems Engineering and Set-Based design.

If you would like to know more or need help, feel free to reach out.

One of the principles behind the Agile Manifesto is using an efficient and effective method of conveying information to and within a development team (the best way being a face-to-face conversation). The following points reveal why email is ineffective for productivity as well as a big source of frustration.

Email overload

The average worker will receive 122 of those emails each day, of which less than half will contain relevant information. When people are bombarded with all of this superfluous information, they simply bulk delete or skim through, missing important information that is buried. The sheer number of messages we receive leads to the most important ones getting lost, deleted, or forgotten. In addition, people are easily frustrated when their workload becomes overwhelming. Just one email can prove highly distracting. Just consider all of the newsletters and blogs to which you’ve subscribed. Reading through a single one can consume an inordinate amount of time, distracting you from the task at hand. In fact, studies show that after reading an email it can take up to twenty-five minutes to refocus on the work you were originally doing.

Wasted Time

The McKinsey Global Institute found that the average employee spends 13 hours a week checking, reading and responding to emails— eating up 28% of the work week. With less than half of emails deserving attention and many going unread, this is a lot of wasted time. On top of this, simply getting back to work after answering an email takes an average of 64 seconds. This enormously decreases productivity.

Not Made for Collaboration

Email was not designed to be a collaboration tool. From managing projects to troubleshooting a problem, neverending email threads become inefficient, confusing, and bad for productivity. With many collaboration and project management products available, email should never be the place you turn in order to stay on top of tasks and projects.

No Accountability

With email, there is little accountability. There no way of knowing if people have read an important update and anything can be chalked up to, “Oh, I didn’t get that email.”

Emails don’t support engagement

Email lacks the easy user experience of social commenting and as soon as more people join a conversation it becomes confusing (Email hardly ever stays on topic).

Email does not facilitate continuous feedback

People need feedback. Consistently. Top-down (as well as peer-to-peer) communication is essential for keeping this loop running effectively. But giving regular feedback via email takes a lot of work.

In comparison, modern communication channels like document solutions with embedded commenting systems encourage interactive conversations between peers, while push messages allow to give better feedback in less time. Plus it can be targeted and sent “on the go.”

Ineffective Content Repository

We’ve established why email is ineffective for collaboration but it is also a poor repository for company knowledge. Searching your inbox is always a headache. You rack your brain for a keyword or who sent the email or worse what date it was received. There is simply no way to remember all of that detail when your inbox is clogged up with hundreds of emails.

Secondly Email content is scattered and has no guardian. When people leave or get assigned into another position parts of the truth get lost.

Conclusion

Based on the above Email is ineffective for Agile communication. For an agile drive to succeed, it’s crucial to take a strategic approach using a solution that effectively connects teams in real time so they can collaborate, get answers and share information in an efficient and effective manner. Even more, we must ensure communication is unlocked to all levels of the organisation.

Note

Personally I favour the Atlassian suite to structure project communication but you can use any collaboration platform that meets your needs.

Agile and scrum are crystallisations of a mindset and a way of working. You can have that mindset and work a certain way before it is given a new shiny moniker.

Coming from Rotterdam University of Applied Sciences in the same year as Arie van Bennekum, co-author of the Agile Manifesto, his role in the Manifesto is no surprise to me. We were educated to focus on delivering solutions with the freedom to use whatever platform we found appropriate in order to provide working prototypes. The mantra was to write self-documenting coding to allow for as little documentation as possible. We learned to embrace change (in technical possibilities and in stakeholder wishes) as a natural state.
It is not that difficult to find the 4 Agile values there and to derive the Agile principles.

Very early on we learned to design small functional bits of software with a teacher that hammered the following quote in our heads:

“Any intelligent fool can make things bigger and more complex… It takes a touch of genius and a lot of courage to move in the opposite direction.”

We learned to put all the stuff that we wanted to design and develop in a Javelin sheet (a very old spreadsheet solution), discuss the amount of work it would be with the team and then prioritise and distribute the work. Every day we would align on progress and every week we would evaluate if what was in the pipeline was still valid. Looks rather a lot like Scrum/Kanban don’t you think?

My biggest disappointment came when I joined the SVB and was pushed back into SDM and other painful ways of the old. That’s when I decided to do a KeyNote at a Clipper developer congress about customer oriented software development and shortly thereafter I was hired by the founders of Centric, Cock Mudde and Albert Oegema to start working that way at the Volvo Truck Corporation.
From then on I have been able to take those practices and work with an Agile mindset in a Scrum manner.

And so to conclude, this is how you can be Agile and work in a Scrum way for 25+ years.