A mature maturity model for continuous delivery including culture and DevOps

Do you love the idea of a model that rules them all? I bet you have, we all have 🙂

“Devops has huge business benefits: Statistics show that organizations that practice devops outperform the SMP500 over a 3 year period, high-performing IT organizations have 50 percent higher market cap growth, and so on.”

I have ben fan of models in my whole life (kind of, since I remember anyway). The idea with a model it that it’s not a process. It just helps you understand things. While a process is how you shall navigate. I’m not fan of processes. I love to create them though, for others. It might sound rude but I’m a creative person that love to be on the top of the wave. Processes can’t make me think outside of the box or live outside it so I just creates them for others that don’t have time or interest to be on the top of the wave all the time. My daily activity in my head loves the ideas of innovation, efficiency – how can we make it easier and still with high quality? How can we do it in such a way that we do not need to do a lot of bad work when we want to change something? These are the questions I always ask myself every day in all areas. I can not stand the feeling to stand still and be smug. I am a thinker who loves changes. I’m curious person.

The last 10 years or so I have always been interested in different working models/processes. Therefore ALM (Application Lifetime Management) became an interesting area for me. Agile processes, gamification and so on.

We have this constant goal and vision to work towards something better. It shall be easy to make adjustments to the code and the architecture. It shall be easy to delete code that is not used anymore and, last but not least it should be fun and innovative approach to work with software development and deliver a smile on the customer’s lips every time. Faster deliveries and keep up with the competition has never been more important than now. Before, it was easier to become complacent and just sell on. Today we cant work this way if we want to keep up.

drastolen

Today we talk about agile delivery, continuous delivery. We’re talking about spending less time on code problems with smart and effective continuous integrations. We talk about the importance to measure value via monitor behaviour etc. We’re talking also about saving time in testing, operations and so on in order to keep up. To help and make managers and buyers less busy, several companies worked to develop various maturity models. With the main goal to be able to run faster delivery and early take part of the digitalisation and its digital transformation taking place today.

I wrote myself a Swedish post on my LinkedIn about five maturity levels for the  transformation regarding better continues delivery benefit.

Level 1 – A few develop are the organisations super heroes (Ad hoc solutions)
Level 2 – Time-Boxed releases
Level 3 – Regular deliveries
Level 4 – Release Command
Level 5 – Hypothesis-driven development

I recently wanted to find a model that explains all this in a more technical level. To help companies to identify where you are in the area of DevOps, test, code, culture, processes and so on. I have read four different maturity models from four different companies. But I didn’t like them. Most of them feel like they were created based on other companies’ problems and not based on a general level. A colleague of mine gave me a link to a model that actually is a great addition to the five levels I previously presented.

The model comes from the company Praqma. Not only that it is presented nicely, it is also spot on based on my thought and experiences in that field. The expert step is a great addition to #NoEstimate, Lean Startups with Hypothesis-Driven-development/Design and Pain-Driven-Development/design as the level 5 above.

cd-maturity

You can read more about it here
http://code-maturity.praqma.com/

If you are interested how you can work or how a system need to be designed and what transformation you need to do to reach the expert level, don’t hesitate to contact me or read my blog and forthcoming posts.

Who is Johan Normén?

Johan Normén works as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015 and member of IDG Expert Network Team

Twitter: @johannormen

Advertisements

How to make Lean UX with A/B testing fun in ASP .Net MVC? Part 1

A/B testing is jargon for a randomized experiment with two variants, A and B, which are the control and treatment in the controlled experiment. It is a form of statistical hypothesis testing with two variants leading to the technical term, two-sample hypothesis testing, used in the field of statistics.
Source: https://en.wikipedia.org/wiki/A/B_testing

download
And some other nice explanation:  https://vwo.com/ab-testing/

It’s really hard to change or add something and know if it’s a success or a failure before we have test it on real users. In Lean UX it’s important to do this test process as cost effective as possible by decrease unnecessary waste without skipping important work. The best feedback is when you let people use it and see if they like it or not. You can test wireframes, design sketches but that’s not the same as test It for real in real action. Many users will see this cool new thing as a sketch and think; that looks really cool! but is it really that cool when it’s implemented and live in action? Not all the time, maybe some times but we can’t be really sure before we can test it. In Lean UX A/B testing is one approach that can help you get early and rapid feedback if the idea is great or just a new pain for the user. The core idea of Lean UX is to aim small and hopefully shoot big. In other words, do as little as possible and test it before you spend too much time on your ideas.

Let’s see how ASP .Net MVC can make this by just add very little code to make A/B testing fun and easy. 🙂

I love to use the creativity to think; – how can I add something simple that works and also gives me many other possibilities? It’s some kind of evil obsession I have and that’s also what I love most about software design. In this case I will show you how you can add some code to make your page not only A/B test friendly you can use this idea for other things like themes, change layout bases on personalisation and you can even use it to give your user some luxury in e-commerce sites and so on.

In the software, there are thousands of ways to solve the A / B testing. What I found very useful that also decrease waste from more complex solution is to copy the view you want to test to a new location and add changes to that new file, and then let ASP .Net MVC show just that new view based on some business rules. I also want less code, and it shall be easy to remove my test-view without too much work. Therefore, I want to use the view folder and it’s files and not manipulate controllers if not needed. It’s more waste to add new controller if you can use the the you already have when you want to test another layout. My approach doesn’t stop you from A/B test controller as well if you want to add that feature in the future. Remember I’m fan of Agile and Lean approach and principles like KISS (Keep it simple stupid) and YAGNI (you aren’t gonna need it). That’s why I keep things as simple as possible and expand it if more advanced featured is needed later on. 

This is my goal:
Let’s say you want to test your home view, you can then easily add a new folder inside the view folder for example “B Testing” and add your home folder and its view in there. And then add some changes to it… DONE! Cool right? In less of a second you just made a A/B tested home view. Sell it for 5h of work 😉

ab_1a

To make this possible I want to let my view engine look for views in special folders but fallback to the original if there is no files in this special folder. ASP .Net MVC do this by default. Like this setup:

ab_1

I call the variable theme because I can use it for other purpose than just A/B testing too.

Lets create this
Go to your ASP .net MVC project and add a new class that implements the interface IViewEngine from System.Web.Mvc. And implement the view engine code.

ab_2

Then add the folder locations within a method. I call mine CreateThemeRazorViewEngine

ab_3

Then I create a RazorViewEngine and configured the Partials, View and Master locations to the new folder structure of mine. In this case ASP .Net MVC razor will act as normal but start looking for files in my theme folders if they exist.

I love the factory and provider pattern so I will use those. As factory I will use DI/IOC framework, I like Autofac but you can use whatever you like the idea is the same.

I start by creating one IViewThemeManager interface with one method GetTheme. This interface is the one we use on all the ViewManager providers that will handle all the business rules based on why you want ASP .Net MVC call for another view or partial.

ab_3a

And then I implementation my factory method to the ViewEngine with the IOC and some error handling.

ab_4

If there is no IViewThemeManager provider configured it will give me null and return the default Razor view engine. That’s why I use the _fallbackViewEngine. If there is an IViewThemeManager provider registered I ask for the Theme which in this case is the folder name I want the view engine to use.

After that we need to tell ASP .Net MVC what Engine it shall use so we need to add some code for the methods implemented from IViewEngine

ab_5

In this case I call my CreateViewEngine that will return either the default engine or mine.

Here is the full file:
ab_6

Now go to Global.asax and clear all View Engines and add this new one in Application start.

ab_7

We can now run the project and everything will work as normal. This because the resolver can’t find any IViewThemeManager provider yet and fall back to default.

ab_8

Now it’s time to add the A/B testing business rules. In this case I want to know if the “Learn More >>” button gets more clicks with another text. So I want some user to get “Learn more >>” and others “Want to learn more?”

First I copy the index file in my home folder to a new home folder under “B-Testing” and just change the text on the button nothing more.

ab_9

ab_1a

Then I create my IViewThemeManager provider. My ABTestingViewThemeManager.

ab_10

After that I will add some simple rule. In this case I just send them to my “B-Testing” view folder if the date time second contains number 2. (Just for the test, ok? Real A/B testing might need more complex logic and maybe even som settings, depends on how important the function is, remember don’t make it to complex if not needed. KISS 🙂 )

ab_11

After that I configure my interface and provider with autofac.

builder.RegisterType<ABTestingViewThemeManager>()
.As<IViewThemeManager>()
.InstancePerRequest();

And when I run the page and if the DateTime.Now.Second contains number 2  it will use my B-Testing view instead.

ab_13 ab_12

I also added the view rules for partials so you can just test a partial as well if you want to, you don’t need a full view, you can use the default one that just calls for your partials.

Just copy your A/B partial to “B-Testing/<your controller folder>” and this code will take care of that too.

And if you use partials to render templates for example angular you can even test unique directives and web components if you want to. Just add the angular template in your partial and copy just that partial and its folder structure to the “B-Testing” folder or what name you prefer.

You can also add a provider that will give some user a whole new view, layout or webcomponents layout if they are lets say “pro users”. Just add a pro user folder and create a new IViewThemeManager provider that check if the user is of the role pro or something like that.

Happy play around.

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @johannormen

How to color cards in Microsoft TFS Online. Add color to a Lean hypothesis card.

I think most of you have heard of Lean Startups and maybe also UX for Lean Startups. Ok if not I will explain it shortly.

In Lean Startup you use something called hypothesis instead of User Stories if using Kanban or any other tools. The main different with a hypothesis regarding a User Story is mostly the way you describe it and its purpose. A user story template often look like this

As a <type of user>, I want <some goal> so that <some reason>.

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

In Lean startups you use hypothesis that is an assumption when user story is not.
Lean Startup strategies are designed to test assumptions about customers and the market target.
While User Stories are the description of a technical solution that we can test in our system then Lean hypothesis is a description of an assumption we need to test on the market, the users.

The template looks something like this:
I believe [target market] will [do this action / use this solution] for [this reason].

You simple add that description on your card (post-it) or digital Kanban board. I often want different colors on my cards to increase the visualization better. Bugs are red cards, things I need to look up maybe blue cards, user story a yellow card and hypothesis maybe green and so on. I want fast feedback what’s going on when I look at a Kanban board that’s why I add more visualization to it so I don’t need to spend too much time understand what’s going on in this sprint or iteration.

In Microsoft TFS Online you can’t change the color of the cards based on card types when this blog-post is written (2015 Oct 9). But you can change colors on the card based on styling rules in TFS Online. The cool thing with styling rule is that you can add criteria based on mostly anything that exist on a card and make it show up in different colors. In this case I use Tags and the contains criteria in this demo to add another color to my hypothesis cards. I will show you how to do this in TFS Online.

First of all open you TFS Online project. Add a card. In this case I added my first hypothesis .

1

Then go to the board settings (The icon in the right corner (1)).
2

Go to the Style option (2) and add a new rule (3).
After that just add your criteria. Remember that you can add many different criteria. In my case I will first add a criteria for a tag. And next add a criteria that check if title contains some words. Like the words “I believe” as the hypothesis template starts with.

3

On the image above I added a rule based on tags. If the tag HYP is added then show green card.
Next image show you how it can look like if the criteria contains text in the title .

3a

If using Tags make sure you add your tag to the card.
4

If you used the “contains” criteria just save the settings. And the card will end up green on the board.

5

That’s it… Happy playing around.

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden.
He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

Twitter: @johannormen

Can we use IoT (Internet of Things) with Lean UX?

Almost 79% of global companies already use IoT technologies to track their customers, products, premises, or supply chains today in different ways. And it does not stop there, many large companies spend more time collecting data and use technologies that will teach them what people might want or not. Some companies even use it to see if they can prevent crimes before they happen, like in the Minority Report movie. So why do I ask the question if we can use IoT with Lean UX?

Lean UX is not new. It has been around for many, many years but never defined as a concept, as with many other things. Lean UX has taken ideas from UCD (User Centered Design) with CD (Collaborative Design) and the iterative process itself to meet the MVP (Minimal Viable Product) goals and measure the result when measurements give the most feedback. In other words, you mostly know if something was great when people ask for it, or you can see if they really use your idea and like it or not. UCD guesses and assumes things while Lean UX goes further to really investigate if it was used and if it needs to be improved in the next iteration and so on.
It’s also very common that you add features in products but rarely delete features that no one uses anymore. The goal of Lean UX is to help you with that as well.

The big difference with UCD and Lean UX is that UCD is mostly common as a tool in up-front processes like waterfall. Lean UX focuses on KISS (Keep It Simple Stupid) with small iterations and collaboration with the whole agile team – not just the UX Designers.

One interesting idea of Lean UX is that it’s a data-driven approach. Instead of thinking Lean design as being driven by data, you can see it as being informed by data. That’s why I think IoT will be a very interesting topic in our UX world.

Consider this: IoT can help you in the future to understand what temperature you want to have in your home based on the hours of the day. The systems will know this by collecting data from you. What temperature do you often set at 3 PM? Did you complain on the internet that it’s too cold in your home? And so on… All this information helps analysis tools with understanding what you probably want so you can spend time on more important things than complaining about the temperature at home. The system will help you get the temperature you want before you even notice it.

We also have problems today with people that turns off advertisements with ad blockers. So you need to find new ways to certify the customer. To do so you need to understand them. To understand them you need to monitor them, collect data about them to help them get what they really want. When Lean UX is data-driven you can simply use the IoT ideas to analyze and find out where the trends point, what people feel uncomfortable with and so on. In the near future systems will almost know what you are thinking and give you what you ask for before you even know it. Scary? I know. But with a bit of luck it will give us time for more important tasks. To analyze what people might want we can use the IoT to create better UX and features before the customers even know about them.

For example, Apple’s Siri already helps you more than you know. Microsoft Cortana and Google’s knowledge of what you often seek for is already a part of this.

Welcome to the future…

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden.
He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

Twitter: @johannormen

#NoEstimate, successful projects in an agile world. Part 1.

It is known and has been documented that up-front work rarely delivers more than unnecessary time spent in our IT projects. CHAOS Report 2005 showed that this traditional approach was not viable. Approximately 16% of all projects were delivered on time 2005. Over 80% was delivered after budget and time, and the rest was more or less failed projects. Only 9% of the 16% successful projects had been supplied with all the requirements customer wanted. 78% of those 16% had about 74% of the customer’s requirements and expectations.

And the size of the companies did also matter, small and big delivered different results in losses on budget. The large companies went over with a budget of about 180% while smaller companies went over by more than 220% in several projects.

That means there is a 75% chance that a project of 1000 hours will cost a small business about 2200 hours for all the requirements.
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

The numbers were changed in the CHAOS report 2013 when agile methods have reached their success by 2005. Approximately 39% of the projects was delivered in time and budget with a 100% agile methodologies such as Scrum, Lean, XP…

Why does so many project fails?
The answers are many, it is everything from how we manage projects, knowledge in organisations, how we manage our customers and attacking redundant work.

A big mistake is that we are so fixated with time. We use time to estimate the costs. This approach automatically more or less means that you agree to an up-front process that’s likely limit the customer the opportunity to request changes and you for welcoming them.  Customer thinks that estimate is almost a contract when we are done. This approach is often called Budget-Driven Estimation or Promise-Driven Estimation. And the real problem here is that customers know that estimate is just a “guess”. But they always refer to it as a promised timeframe. So in the community people want to change this word to something else though estimate is almost always converted as a promise. It would be much better to call it. “We guess it will take 1000h!” instead of telling the customer “the estimate is 1000h.” You get the point right?

And remember that estimate does not actually tell the story about the delivery time frames. The actual delivery time depends on current priorities, WIP and lead-time. But! When a customer asks “how long?” and we answer “eight weeks”, or “1200h” they think the clock has started, and expect to see results after 8 weeks or exactly 1200 hours. But the reality may be that the team will not begin work on the basis of existing PIA and priorities.

Another reason is when leaders see the team members as a developer that you can move around or replace whenever you want. We believe that a developer is equal another developer in skill and knowledge.
Two brothers created in 1980 an idea that people are not equals because they have the same title. They identified that people attack problems differently based on their experience and knowledge. And therefore created the Dreyfus model.
To rank where people exist in all there unique skills.
Source: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

It is also common to add people to an ongoing project and believe it will create greater efficiency when it’s usually do the opposite. Each new person has to be trained in collaboration, customer requirements, knowledge of the customer, etc. and it usually takes focus from an already productive team. “Nine women can’t make a baby in one month.” It’s called The Brook’s law.
Source: http://en.wikipedia.org/wiki/Brooks%27s_law

To prevent much of this we can focus out processes on the 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

It is important to keep an open dialogue with the customer to ensure that risks are lifted up early on the surface as soon as we learn about them.
Then there is also plenty of time to reduce them. Clients / stakeholders do not like surprises as for the development team!

An estimate should never be treated as a commitment or a promise. It’s not a contract. Therefore, avoid negotiating with time to calculate the budget. Instead focus on the value for the customers and charge for them instead. Be value-oriented not time-oriented. (Part 4 in this series will show some ideas how you can get paid and sell your projects value-oriented.)

So when estimate seams so bad, do we need them? Yes and no.
You can read more about it and #NoEstimate in my Part 2. (will be published soon.)