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

How Pain driven development(design) (PDD) can be used as an extension to Hypothesis driven development (design) (HDD)

Earlier I wrote a little bit about HDD (Hypothesis Driven Development) and also how you can use it as an example with Microsoft .Net and JavaScript. This time I will talk about something that can be used as an extension to HDD.

In the topic I added the word (design) after the word development. I did this for a purpose. When we talk about development we usually refer it to just code, but the whole process even if it’s visual design or system design you develop something. But sometimes organizations just do design or work on just the visual design. The process is the same even if it’s in code or in the visual design or even on a paper.

While HDD is a story about an assumption/idea that we need to measure to see if it’s worth implementing. Pain Driven Development is an extension when your product enters the state of management. You will still use HDD for new features but PDD when you need to understand how you can make your features better.

“If you can identify something that is causing people pain and you can develop a product that takes that pain away, that product is very likely to be successful. The goal is to find the most important pain point and then to find a way to solve that pain for people in a usable way that doesn’t actually cause them more pain.” – Laura Klein
PDD is when you focus on the pain and frustration your application generates for the user. The question you ask the user is:

– How does the function make you feel?
– What is complicated with the application?
– What can make your work easier so it wont generate frustration or irritation using it?

You can use PDD as the process to make the application easier for the user. And of course HDD to test the hypothesis of the ideas you get from the PDD process. They are very nice to use as a synergy to each other. And the result will mostly give the user what they want.

If you use it in your development process, it’s fine. If a developer scream WTF (you know the WTF / minute principle right?)

wtfm

Code shall be easy to understand, easy to use. With PDD as a part of your code quality process you can easily find pain points that probably need to be fixed as soon as possible or in a near future.

You can also use PDD in your organization. Isn’t it a real pain that you only got 2 toilets for 100 people? 😉 You get the point.

 

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

Twitter: @johannormen

 

 

Hypothesis Driven Development with example

My previous blog-post was an introduction to HDD (Hypothesis driven development). In this blog post I will take it a step further and give you an example how you can use it and how easy it can be and how it can change the way you work entirely to a new level.
You can read it [here].

Remember:
HDD is an experimental driven process, it’s main goal is to find out if a certain idea generates ROI and happy users. To get fast result you will also need fast support to evaluate your experiment, if you want to evaluate the idea in production I prefer a smooth decoupled architecture and a mature CI & CD organization. It’s not a must to, but it will really decrease development time and cycle time.
Sadly, I have no maturity model written in English yet. You can read one I did in Swedish on my LinkedIn posts [here]

Let’s start the story.

Team:  A cross-functional team with talent people regarding:
Design, UX, Coding, Testing and so on. And also including some market people and product owner.

At a meeting with the customer and team a team member (TM) got this cool idea regarding an e-commerce platform.

– What if the stock value changes in real time? Wouldn’t that be cool? Maybe it increases the conversion rate? The users might be stressed that this nice shoe will get out of stock?

A business person (BP) responds:
– What will it cost? Can you estimate?

– I don’t know, and I don’t. And I don’t know if my hypothesis even works. Can’t we skip this estimating and cost discussion and find out and then see if it’s worth implementing at all?  (TM)

– How? (BP)

– Let’s just do some A/B testing and fake a simulation of stock value changes and monitor if the user will buy the product more often or faster than today? If we get an 2% increased conversion rate it really worth implementing isn’t it?  (TM)

– Yes, you got a points there, this Sounds interesting. (BP)

Instead of creating User Stories the team now write Hypothesis stories.

Real-Time stock value changes
We Believe That
real-time stock values on the product page
Will Result in improved customer engagement and conversion
We Will Know We Have Succeeded When we see a 5% increased speed and about 2% conversion increase from the time the stock change in real-time till they press the add to cart button.

The meeting generate lots of hypothesis stories and the product owner can now prioritize them based on the ROI for the result outcome.

– A 2% increased conversion rate is really nice. Today we got like 5000$ each day, 2% will give us about 100$ more. In a month it’s around 3000$. If the experiment works and generate this value; You can spend around 30h of development time and we still get more money than not implement it at all. (BM)

– Yes you can say that, but let’s not convert it to time yet, let’s see if it’s worth implementing at all. Because if we spend around 10-30 hour for this feature and it will not increase conversion at all; we just wasted lots of money for developing a crappy feature. Let’s be smart and just spend time creating features that generate values in short and long runs instead. Assumptions is not a good thing. (TM)

– Ok, we can give it a try, because we have done so many bad assumptions we even can’t monitor at all. (BP)

The Product owner decided to activate the experiment and tells the team to do the fastest possible implementation to get information to see if this hypothesis will generate values at all.

The team gathered as usual at a stand-up and activated the work of the hypothesis.

– So what is the fastest possible solution to get rapid feedback regarding this? (TM)
– We can ask the customer?
– Nah, the customer might say, cool feature or – Do you want to stress us even more?
– Ok, let’s implement a test in our code and monitor the outcome?
– Sure, what’s the fastest way?
– This is part of the UI so let’s do it simple with some JavaScript. The only thing we need to understand is if it works. So there is no need to make it perfect. We do not need to add back-end functionality to get this information either. I can type a JavaScript that just randomly decrease the stock-values on some products. And then monitor with our application-insight code if they will press the button faster or not. It doesn’t matter if the stock value is a faked value for a while… If the value is 5 or 4 doesn’t matter that much.
– Nice, cool this will take us around 15 minutes or so? And thanks to our CI  & CD approach the feature will be out within 20-30 min or so and we can then start monitor it. If the result is good, then we implement it all the way with tests and quality in mind.
– Cool, this is nice, if the PO asked us to estimate it and add management work around it and do all the other stuff we do for a user story it would take longer cycle time than 30 minutes for just get started on this one. We aren’t wasting anything here, just getting knowledge and information if the idea is worth implementing or not. We will save around 15 minutes and also get the information if it’s even worth implementing. It’s much better than assume it does by implement it and hope it will generate values.

The team agreed.

Liza loved the idea regarding NoPSD so instead of spend time on working with PSD files or other tools for design she just opened the SASS file (css manipulation) and added three new classes with three different color. Green for normal stock values, Orange that indicate near out of stock and red that indicate very soon out of stock.

.stock-Normal
{
     color: #38893d;
}.stock-Warning

    color: #fe8f01;
}
.stock-Critical

    color: #be0000;
}

Thanks to nice SASS structures it just took her 2 minutes. When she pushed the code to the source control it automatically generated a new css file that got released into production, this because the team had nice CI & CD approach. (Why not release it? It will not hurt anything though nothing using the classes at the moment anyway.)

The front-end was built on AngularJs and the stock area was created as a web component and rest of the system is based on ASP.Net MVC and Web Api. Meanwhile Liza added the css John added a feature toggle in the code and took the html from the web component template and added it to the new feature for the hypothesis.

The feature toggle framework they use uses one configuration file to indicate if the feature is on and off.
They simple add it as an appSetting in web.config or appSettings.json (if using ASP .Net 1.0 Core).

“IRLStock” : “true”;

The team uses a framework that uses a C# class as a feature toggle so they easy can remove the class and get compilation error where the feature existed, so they do not forget to remove the code later on.

public class IRLStock {}

The code with razor syntax (ugly code? I know but much faster than create a new web-component to get the result from this experiment, it’s important to not waste unnecessary time for a more complicated solution, then you missed the whole point. This code will be deleted after the experiment anyway. For experiments it’s just waste to add sugar to it.):

@if(Feature<IRLStock).Is().Enabled)
{  
     < script >
… a script that just gets a random number between 2-6 seconds…
… this number just trigger a interval eg.
setInterval(changeStock, randomNumber);..
..
and set a new class to the element…
getElementById(“stockDemo”)…

< /script >

< div class=”stock-number” id=”stockDemo”>< /div >
< div class=”stock-text”> In Stock< /div >
}
else
{
<stock-indicator></stock-indicator>
 //Old code that works. If feature is turned off the ordinary code will run. An easy way to turn on off features, you can even turn on feature in dev mode but disable it in production mode…

}

John started the page to see if the script worked as intended. He didn’t create any tests since the code will be deleted as soon the experiment is done.

It worked. So he pushed the code, the CI & CD took care of everything and now the experiment was live.
It took him only 15 minutes.

And the result:

 

Two weeks later:
The PO asked the team how the experiment went. The team showed the PO the monitored data they have gathered. It didn’t show any direct speed increase only 0.5% faster than average. But the conversion rate was higher than before. 1.8%. So the hypothesis with the goal of 5% increased speed and 2% conversion rate did not work. But it still generates 1.8% conversion rate. The PO was not fully convinced if the feature was that good so he wanted to test the experiment one more week.

One week later:
Still the same result 1.8%.

– Ok the experimental code just gave us about 2400$ extra income. That’s nice, lets implement it. Is it possible to get it done within a week or two? (BP)

– Sure, we already have the infrastructure with SignalR since before so we just need to add a new REST API in our Asp .Net Web Api module for the product page. We already have code for retrieving Stock   values in our validation of the cart so thanks to our SOLID approach with SRP (Single responsibility principle) we already have a repository method to retrieve the actual stock value for an articleid.
The style we added can be reused, no need to change that; we just need to add the event handling in our Angular web-component for the stock indicator. It will not take that long either though we only need to act on the event triggered from SignalR and add the new stock value to our view model. Add some code that switch the class based on the stock value. I think with tests we will have this implemented up and running within few days or in a week. Especially thanks to our CI & CD approach and our architecture. (TM)

– Nice. Let’s create a user story and add it to the backlog (BP)

Summary
Sounds too easy right? Like a Utopia? I know, but it’s not. With good agile organization mindset, with well-educated team, with good CI & CD, DevOps and architecture it will be easier than before. As humans we mostly do things too complicated, and thanks to a lack of slack in organizations you don’t have time over for the team to be more innovated and creative in learning.We need time to invent things easier and better than last time. Continuous improvement is so important so don’t waste that benefit.

 

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

 

 

Implement HDD (Hypothesis driven development – Part of Lean Startup) with #NoEstimate

I remember when I study Information Technology in college (1995), we published local newspapers for our school. I’m not that good writing articles so I mostly worked with the layout and ideas to make the paper look great. My talent was used for the cover and also to make the paper more user friendly. To do this I tested lots of ideas with the team and with survey,  interviews and we monitored what worked best for our readers. We also had another competitor who also launched a newspaper at our school.

I remember one time when I wanted to add a little tag on the upper left corner. A tag with black background and white uppercase words explaining what section you where on. Like SPORT, MEDIA, GOSSIPS, GAMES and so on. I wanted this because I thought it will make it easier for the readers to remember what section they where on and also an indicator so the reader can jump to the most interested section without reading the table of contents. We added this section topic tags on each page as a test.

One week later we asked the readers what they think about the new version. Most of them pointed out that it was really nice with the section topic tags but they wanted to us to add the page number up in that corner as well. Some other stuff was bad so we removed that in the next number and added the page number in the upper left corner as the user wanted. We used reusable template so it was an easy fix.

Two months later, our competitors also took this idea to their newspaper. At this point we got a better colored RGB-printer so we removed the section topic tag names and colored the background instead. Why read the topic when you can see the topic? Blue for sport, red for gossip, yellow for fashion and so on. It worked even better, the user thought some colors felt wrong for some sections, so we changed the color based on the user inputs and they where happy. Guess what our competitor did later on?

Some ideas were great so we kept them even if the competitors copy us. We still sold more newspapers then them. Because we tested new ideas and listened to our readers all the time to get rapid feedback. We engaged our readers. And it was important for us to fail fast if our ideas were bad. It’s our readers who pays us so it would be bad idea not listen to them. How often do you ask your users what pain them the most with your software and what change they expect? What functions can you delete to clean up the code from smells and other unnecessary things that are not used anymore? Do you monitor how the user use your software?

In this post I will give you some introduction and guidance of some practices regarding how you can make this possible with HDD and #NoEstimate.

HDD (Hypothesis driven development)
As development industry continues to mature, we now have an opportunity to leverage improved capabilities with Continuous Design and Delivery to maximize our potential to learn quickly what works and what does not for the users. To do this we need to engage the user or monitor the user’s actions. We need to learn from them not just teach them.

Are you familiar with User Stories and maybe even BDD (Behavior riven development?)

User story focused on capturing requirements for what we want to build and for whom and why. The main goal is to enable the user to receive a specific benefit from the system.

User story format:

As a…  <user>
I Want… <something>
So That… <I receive benefit>

User story are mostly common in the process when some market people or it-leaders have decide what shall be built. It’s not uncommon that the selection of user stories is based on the estimated time rather then the real user value. – Is X that big? Then let’s skip it, we need to give the user features fast and can’t spend time on the most expensive once.

(BDD) Behaviour Driven Development takes us to the next step. It aims to improve the user stories by supporting communication and collaboration between developers, tester and non-technical participants in a software project.

In Order To… <receive benefit>
As A… <role>
I Want… <goal/desire>

User Stories and BDD stories are both often created within the development process as a result of already prioritised features that will be built based on our definition of done and so on. But how value-driven is that? Do you really know if that feature will be used by the users? They might say “we need it!” if you ask them, but will they use it? Is it worth spending time to estimate something you are not sure if a user really need? Is it worth develop a user story with high quality and release it month later if the user wont even use it anyway? What about the feature Y you decided to skip because it was estimated to high? We need to view our work as an experiment to really find out. We need to ad a better process for innovation and monitoring what pains the user most to understand what benefit them the most. We need to learn from the users, not the value of an estimate or assumptions.

When viewing work as an experiment, the traditional story process is insufficient. As in college when we defined the steps we needed to achieve the desired outcome. We need to observe if our idea (hypothesis) is valid.

If we observe signals that indicate if our idea or hypothesis is correct, we can be more confident that we are on the right path and can alter the user story process to reflect this.

Keep in mind that a hypothesis that was once valid may later be disproven when markets change. Markets move, so you need to continually ask whether the business model is still valid or not. HDD is value-driven and the market is too.

A hypothesis story can be implemented with different technologies and tools, the main goal with a hypothesis is the explanation what action you need to implement to get the indication if it worth implementing.

We believe… <this capability>
Will result in… <this outcome>
We will know we have succeeded when… <we see a measurable signal>

Examples of Hypothesis-Driven Development user stories are;
We Believe That real-time stock values on the product page
Will Result In improved customer engagement and conversion
We Will Know We Have Succeeded When we see a 5% increased speed from the time the stock change in real-time till they press the add to cart button.

Why I mentioned #NoEstimate in this post topic is because you do not estimate when wotking with hypothesis, you just use the easiest and fastest tools to reach your goal, so you can take action if it’s worth implement it as a full qualified feature in your system or not.

Lean startup and UX for Lean Startup will explain more how. I will not cover this in this blogpost, it’s almost to big as is.
A hint: Instead of write user story, spend time estimating and then build all the technical stuff regarding real-time stock value changes, just add a simple timer in javascript that decrease the stock value on different products to see if the user reacts on it. If not, then you have saved lots of time not implement a fully working feature. I can promise you that it’s worth spending less then one hour to implement some test data rather then add a push or pull system (with eg. SignalR?) that monitor the stock values in the e-commerce platform you use.

To use value-driven-design and HDD you need to change the way your organization work and also the traditional mindset of yours.

Some methods you need to add to your organization are:
– Increase observations
– Formulate a hypothesis
– Design an experiment to test the hypothesis
– Evaluate if the experiment has succeeded
– Conduct the experiment
– Evaluate the results of the experiment
– Accept or reject the hypothesis
– If necessary, make and test a new hypothesis

To make this possible you also need the developers to be more mature in the way they craft. HDD requires that you write code that is easy to test, profile, benchmark, and change. They need to learn about A/B Testing and how to implement it to the code.
A more mature model for CI (Continuous integration) and CD (Continuous Delivery) are also a must for even bigger benefits. Other useful techniques can be feature toggling (can be used for A/B Testing) and also rapid development for releasing and remove measured and monitored prototypes, dark launches and even live ops.

“By combining Continuous Delivery and Hypothesis-Driven Development we can now define working software and validated learning as the primary measures of progress.”
– Thoughtworks

Traditional process vs HDD process

Traditional process
1. PO add epics, features or user stories in a backlog.
2. Team estimate the items
3. PO decide what items need to be implemented (often based on time and cost)
4. The team implement the feature
5. The team release the feature
6. The process starts over from 1-6 again.
(7). Team spend time on supporting and maintain released software.

Result: Something will be implemented and released, but it’s uncertain if its what the users really want.

HDD process
1. The organization make observations
a. Ask the support people what makes the users scream the most
b. Ask the team and acceptance testers what features are hardest to test
c. Interview real users and also create personas if hard to get interview, or use both
d. Record users using the software to get indication of the impression and feelings etc…
e. Look at trends, competitors
d. Monitor and measure the app (buttons clicks, sequence orders, timers etc..)
(Did you know that people mostly use only about 10%-20% of all features in one
application?)
2. Formulate the hypothesis.
3. Design what’s needed to experiment the hypothesis.
(see: Lean startup, Lean startup ux for more inspirations.)
4. Evaluate the result of the experiment
(If you need to implement a monitored A /B Testing and  prototype, remember you need   some time to collect that data. It’s better to wait for a result then spend lots of            unnecessary time to implement something that takes time and never gets used and spend that time on the most valuable features instead)
5. Accept or reject the hypothesis.
(If rejected, start over from 1 or continue from 3)
6. Make a User story of the accepted hypothesis.
(#NoEstimate: There is no need to estimate the user stories, at this point the users have already told you they will use the feature and need it. Save unnecessary waste instead and spend time to continuous improve your CI & CD process instead.)
7. Implement the user story and release with CI  & CD in mind.

Result :
You will mostly spent time on feature users really want that gives you the best value and ROI. You don’t waste time on features that never get used. And the whole HDD process is like an innovation process as well. So you get that as a bonus too.

If you liked this, please read: Hypothesis Driven Development with example

 

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

 

A swedish article with me regarding Microservices

Mikrotjänster är snabbt på väg att bli ett populärt sätt att bygga arkitekturer för applikationer och tjänster.

Capture

Mikrotjänster, microservices, innebär som namnet antyder att applikationer och webbtjänster byggs upp av små delar. Då kanske du tänker att det handlar om miniversioner av tjänster i tjänsteorienterade arkitekturer (soa)? Nej, inte riktigt.

– Det finns flera skillnader mellan soa och mikrotjänster. En är att en mikrotjänst är mindre än en soa-tjänst är och istället för kommunicera med hjälp av scheman och kontrakt så används klasser, då det i praktiken är frågan om rest-lösningar, säger Johan Normén, utvecklare och agil coach på konsultföretaget Softhouse i Göteborg…

Läs mer: http://techworld.idg.se/2.2524/1.652228/mikrotjanster-utvecklare

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

 

 

Why Microservices and continuous deployment (delivery) is win / win

Microservices is nothing new but has become a standard in many systems during the last years. There have been trends in architectures some engineers use them as a silver-bullet. They used the Architectures even if not required by system nor requirements. DNA, 3-teir, SOA, DDD, CQRS, Onion architecture and so on. Is Microservices just a trend that will destroy systems because people will use it as a silver bullet? Maybe! The future will tell. Let’s investigate why microservices will be a good benefit for the continuous delivery approach.

 

As most of you know by now, is that continuous delivery (CD) is an approach to deliver functionality in a smooth and almost automatic throughput. CD is an extension to Continuous Integration (CI) that are the configuration that tells you something will happen as soon you check in your code in to your source control. It can run tests, if it fails it will not publish the system or do something else that’s important four you and your business. I use CI to tell the build server to build my system, run some test and send it to production with continuous deployment.

The different between Continuous Deployment and Delivery is just that deployment automatically deploy your code when delivery just give you a package that you can manually deploy

softhouse_CD_loop2_new3

As always it is requiring discipline in your mindset as well in your code. It will be forced since you release everything in to production. So why is microservices a win/win with this approach?

The opposite to microservices architecture is the monolithic systems, it’s a system with a server where all your business capabilities are grouped into one big product. With continuous deployment and delivery, we just need to release lots of code and run lots of tests, this can be tricky for the benefit of a smooth delivery. Maybe you need to migrate your database, change many contracts and increase a big and complex domain model every time you will push some new feature to your CI/CD configuration. You can save you lot of problem with feature toggling but you still need to release the whole system. This is when the micoservice architecture will save you from lots of headache. Micorservices are like small systems with their own architecture, components and tools needed for your business capabilities. I often explain them as CRUD services for different business areas like a product service, invoice service, order service, authentication service and so on. I also like to refer to them as a SOLID principle architecture on an architectural level rather than just on the code level.

Microservices shall have single responsibility (S) for its business area, it shall be designed open for extension (O), like version controlled REST APIs. A new version extends its functions. With backward compatibility you will have a subtypes of the API (L) and so on.

scaling_agile_model1scaling_agile_model1

Microservices allows you to deploy specific services instead of the whole application when minor changes is applied. You simply deploy that service and only that service code. If you use containers like Windows Containers or Docker you have even better CD benefits though you don’t need to replace any files on the already running service, you just deploy a new container and can easy activate that one as soon you feel comfortable doing so. With other tools like Azure service fabrics you will get even more nice supporting tools for crashes, rollbacks for versions if one deploys fails etc…

Microservcies also benefit from less merge problems despite the fact that it is simple to use different microservices within your team. Discipline implementation of feature toggle minimize the feature branches so you really go Lean with the whole architecture and spend less time on configuration management.
Summary:
– Less code within the codebase

– Less problem with merges if using feature toggling, version handling instead of     branches

– Less problem with deploys though you now deploy the whole system, just a   small part of it

– You will have benefits regarding scaling each heavily loaded service instead of scale up the whole system

And lots more… But remember, this is not another silver bullet, it’s just a bullet of many

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

 

 

 

 

Get rid of some concerns and unnecessary waste when coding for Continues delivery with ASP.Net mvc

I love simplicity I love the creativity of doing things as simple as possible, with the knowledge I have today. I know my knowledge is limited so therefore I always try to get new ideas, networking with people to get new input to create something even better or simpler than I did before. It is my way to continue learning and to improve and grow within my domains.

I do like source control frameworks like Git but I do not love the idea of spending too much time on management of branches, migrations and so on. Therefore I’m in love with the idea of creating SRP modules (single responsibility Principle). I want the integration part within continuous integration to work as smoothly as possible in order to get rid of unnecessary waste from merge-management and so on. This is another reason why I love the idea about Kanban regarding work on one task at a time combined with DoD (Definition of Done) before you start another one. When doing that, you will have finished components, which you can release without any problem. There is no point in not releasing, or there is no harm if doing so, unless it’s a change request of already existing feature that can’t go live at the moment.

No other users will use your components as long it’s not connected to an existing released feature. So in theory there is no problem to work with your main branch most of the time, you do not need to create a new feature branch and handle merge if that branch comes behind and such. It’s just bad waste.

Think of ASP .Net MVC Controllers, the only feature the controller gives you is the action you call, right? So if you release a controller that no one knows exist then the feature can’t harm the system right? Each controller has its own view, its own code, and if you use CQRS or Micro Service Architecture you mostly do not share functions with other controls or modules. The same should be true for other design-patterns like DDD-modules. What happens if you release a controller and all the parts are not fully done yet? Nothing right? It’s just there, it occupies some bytes on the server but it won’t break anything. Why spend time on administrations, configurations, management work regarding different branches when there is no need? You can let those controllers and features go live in your continuous integration, delivery and deployment workflow. OK, if someone manipulate the URL they might trigger this controller and that’s not OK. So I made a tiny little Action Filter that can handle this for me.

What about release you Controller module and only get access to it if a debugger is attached or you are in debug mode? and as soon you put the code in release mode, your controller will simply return 404 status back? That would be great safeguard if someone accidentally figured out the url to the not-done-but-released-feature.

This can be done easy with an [NoRelease] action filter attribute for the control.

1

As soon you try to access this isolated controller action it simple give you a “404 page not found” page if you try to access it in release mode. And gain full access if in debug mode. Other developers can also access your code it you want them to test something for you. I also made this action filter testable and loosely coupled. Which means you can create your own components that need similar functionality.

Maybe you love the idea of reading a configuration that says “release” or “debug” mode. Maybe you want to use as I do in the code example below; check if a debugger is attached or not.

2

I created my own DebuggingService (you can call it something else off course) that just check if the code runs under Debug Mode if it does it’s just returns and code will be executed as normal. If it runs in other modes like “release” mode it will throw an HttpException with the 404 status.

3

Since I started using this attribute I have had no problem to commit and push my features to the main branch and get it release with the nightly build. I spent less time on branches, merges and other stuff and I could focus on delivery rather than management. This because I love the idea of  low complexity in my source control structure. I know it’s not much, it’s no rocket science but a nice to have feature for a more safe integration and deployment of code in your continues delivery life cycle without spend to much concerns that code got released and spend time to prevent that.

4

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

The ultimate agile team constellation

I often got the question “What’s the perfect team?” and the answer is as always “it depends”. The reaction is usually the same; some angry looking eyes. :-), I wonder why?

I can’t answer the question “What’s the perfect team?” but I can give you some tools and ideas in the process of creating a great team. But then it’s up to you to do all the necessary work.

First you need to destroy the fixed mindset of the ideas with roles, process and tools and try to see people in your organization as different talents that you have in your portfolio to succeed with your main — vision and goal. If you can’t let go of your fixed mindset then I can’t really help you. I guess you are reading this blogpost just because you have tried many times creating teams with this not so agile mindset and it did not go as you expected, right? So get rid of tit for a while and we can continue.

Don’t see people as front-end, back-end, designers and testers etc. The layers and the silos creates trust issues, creates bad WIP (work in progress) limits, creates a complex team before a simple productive team. It’s harder to replace layers, and people with a special role if she/he get sick and so on. If your main tool to handle team maturity is reports, forecasting then you are in trouble. Those things is an early indication of ineffectiveness in your organization.

As one of the Agile manifestos point out:

“Individuals and interactions over processes and tools.”

This is why I want you to erase the idea of roles. You can add roles later on if you want to but for now you have no clue why you need one therefore there is no roles ok? Good 🙂 . All you need to know is that you need talents to succeed not roles. You need individuals that can interact with each other not build walls with layers and silos ok? Cool, lets go on.

“Each team should be full-stack and responsible for taking a component from idea right through to production. Don’t divide by layer (frontend/backend/data) nor by activity (analysis/development/testing). Both layer and activity boundaries have rich communications across them. Remember the central importance of Conway’s Law.”
– Martin Fowler

Next step is to understand how your employees and your self are as person and how to motivate the uniqueness within each of you, to do so you need to understand what motivates us. Dan Pink have a wonderful RSA Animation and presentation about this. I suggest you take a look at it before reading further because it will help a lot. https://www.youtube.com/watch?v=u6XAPnuFjJc

“People can have two different mindsets, he says. Those with a “fixed mindset” believe that their talents and abilities are carved in stone. Those with a “growth mindset” believe that their talents and abilities can be developed. Fixed mindsets see every encounter as a test of their worthiness. Growth mindsets see the same encounters as opportunities to improve.”
― Daniel H. Pink

To understand what motives each person in your organization you need to understand them better. Get in touch with their intrinsic feelings. There are many tools for this. One of the easiest tools is using the same ide as with personas and add some gamification in work. Instead of just identify personas for the project you shall work on do it with your organization. Let each individual create their own personas profile with the same main principle and hang in on the wall so everyone can see it and get more knowledge of each other. What’s their motto, what interests do they have? What’s character traits does each individual have? Skills and talents? It’s very important to understand your team mates, because you shall work with them. 🙂 In agile you take command to lead together with your team mates to do so you need to understand how they are, there positive sides, negative sides so you can easily together help each other feel well and get respect for whom you are. The same way you create respect for your family and children of your (if you have any.). Because the domain is called work it doesn’t mean that it shall not have the same principles needed as with the domain family. There are many more tools for this in Agile and Lean Team Startups. But let’s talk about that in another blogpost.

Untitled-1

As soon you know more about the person, who she/he is its time to go to next level. In the real world you always have your employees for loan. You don’t own them; they are there for you if you don’t motivate them they will leave for someone else that does. People will come and go, therefore it’s important to understand that we need to be open for beginners within our organization and a proactive plan to make them step up towards the expert step.  I don’t like the idea to rank a person as a whole. Like businesspeople do with titles as Junior and Senior. What does that say? What’s in the gray zone between this junior and the senior? And when does a junior become a senior? When he/she knows more than the boss or have worked for ten years?  If you think you can work with the same thing you did in one year repeated nine times and then think you have ten years of expertise, you are wrong. Sure you have worked ten years but you are for sure only an expert repeating the same thing over and over again. So as with the roles get out of the box and get rid of the ideas regarding junior and seniors. Business peoples just created them so they can put different prices on their head nothing more.

“…Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done…” – 5th principle behind agile manifesto!

What I found very useful is the Dreyfus model. Dreyfus model does not rank you as a whole it just ranks you for each individual skill and talents of yours. For example, you might be very good in golf and maybe an expert in golf. But for the talent painting you might be novice. You can draw some lines but you are not very good at it.

Dreyfus models have different states in each individual skill of yours. Dreyfus have five states each of them different mindset based of knowledge, experience and skills.

1. Novice – Need rules and clear guidelines.
2. Advanced beginner – Need less rules , uses guidelines, but without holistic understanding
3. Competent – Develops conceptual models, sees actions in long and short terms
4. Proficient – Sees situations holistically, will self-correct based on previous performanc
5. Expert – No longer relies on rules, guidelines, or maxims, works primarily from intuition

dreyfus-model-of-skill-acquisition

Do you want to know more?
Read more:  
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2887319/
or
https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

As soon you have the tools and knowledge about your organization and people’s talents it’s time to create the team.

The best principles for combine talents is like creating software, don’t decide architecture, techniques, platform before you understand the project. So DON’T create a team before you understand the vison, goal and type of software. Is it desktop system? Does it need many integration specialists? Is it a Webb tool? Is it e-commerce? is it a highly transactional system? Does the customer use any own system we need knowledge about? Like Navision? CMS and CRM of any kind? Is responsive design a requirement? This is typical questions in a startup and as soon you know this you can create your fabulous team. Try to pick people as full stack as possible or at least people that can work cross many functions. Like the image below. (The color indicate a unique talented individual, not a role. The columns just indicate required skills needed for the project, they are not roles just requirements for the project. It needs design, it needs a front-end and so on…)

4
The above image describes this.
Blue person has skills in design, front-end development (sass, less, html, javascript) and understand testing. The orange person has some knowledge of design maybe a novice in design but can help with design if needed, the person also has skills in back-end coding and testing. The green person has little talents in front-end and more skill at back-end and testing. Can be a great mentor for the team regarding TDD, system testing, regression testing and so on, And the yellow one is more like a full stack person that can help in all areas if needed.

Tips: It’s not good to put only experts in one team, novice in another. Spread them out if you need to increase the skills overall in your organization. The best suited person to help another to go from one step to the other is the person that just left that step.
So if you need someone to understand angular for some front-end work it’s easier to add an advanced beginner to the team if you also got a novice talented angular to the team, instead of just add experts in that area. The advanced beginner can more likely explain the problem better for the novice person over an expert talented person. Because they mostly talk the same language.

As soon you have your team-setup you can start asking your team what necessary service functions they need. Service functions can be cross-functional mentors, it can be a product owner if the team think they need one, it can be an agile coach, a team leader or scrum master if they feel they need that kind of service. This is a big change from the old traditional organization design. In this case the team create the process. It’s not strange at all even if it feels little odd, the team are the people that shall make it possible so the only correct thing is letting the team get what they need to succeed.

Remember that a development team in agile is not just developers. People in the whole process of creating a project are the development team even the service function competences is part of the team.

Remember, a named method is not a silver bullet so you need to be open minded. You can simple collect information by checking what correlations and interaction you got between the customer and teams. Maybe you need a waterfall approach, agile-waterfall, scrum, scrumban, lean, XP or your own setup of tools and processes. Maybe you just need to use Kanban and no project owner and such because the team are the domain experts together. Why add extra waste when there might be no need for it?

IMG_0515 (1)

It is important to not fall back in old ideas like the project manager where he/she is supposed to handle everything. Then you are back at the main problem again and you have just wasted your time reading this blogpost. 😀

“We can’t be afraid of change. You may feel very secure in the pond that you are in, but if you never venture out of it, you will never know that there is such a thing as an ocean, a sea. Holding onto something that is good for you now, may be the very reason why you don’t have something better.”
― C. JoyBell C.

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