christophe le coënthttps://christophelecoent.wordpress.com
I find it hard to change my mindset but I have to admit it changes my life
Sat, 03 Nov 2018 13:55:09 +0000 en
hourly
1 http://wordpress.com/https://s0.wp.com/i/buttonw-com.pngchristophe le coënthttps://christophelecoent.wordpress.com
How to easily move from Scrum to Scrumban or Leanbanhttps://christophelecoent.wordpress.com/2018/10/07/how-to-easily-move-from-scrum-to-scrumban-or-leanban/
https://christophelecoent.wordpress.com/2018/10/07/how-to-easily-move-from-scrum-to-scrumban-or-leanban/#respondSun, 07 Oct 2018 14:30:05 +0000http://christophelecoent.wordpress.com/?p=788You have been doing scrum but would like to move a “kanban” system: you are concerned you may lose some of scrum disciplines that are great to use; you are concerned it may fail… Whatever the reasons, I am going to show you how to move from scrum to lean kanban in simple steps and nobody will realise you are doing kanban.

Step 0: Change the mindset to “Stop starting and start finishing” – This is really about getting things done: nothing else needs to be done. Not in PROD yet? Not “Done” then.

Something that is not in PROD has no value… This is just stock. Get things done to the end.

Spike – A research activity can give you the knowledge you need to split a complex story.

Paths – If a user can do something in multiple ways, that’s a great area for splitting.

Interfaces – Splitting your story by browser, or hardware, or deliver a complex interface in iterations.

Data – You may be able to deliver value in an iteration by focusing on one type of data.

Rules – Relaxing support for the rules in an iteration can make large stories smaller.

Why splitting user stories into small user stories rather than tasks directly makes a difference? Because this is going to change the dynamic of the team and make everything far simpler. Just one big advantage: no more big stories; things should flow faster; easier to manage.

Step 2: To make it happe, add also a new column named “SPIDRelizer” with an explicit “done” rules to your board – e.g. user stories should be less than a “3”. Hence, team can break down user stories into smaller ones, still INVEST.

Step 3: Add a column “Validated in PROD” – this is just to see the End 2 End flow. Some columns might be missing. No worry.

Now, this is just enough…

What about WIP? Explicit “Rules” for each column? The daily scrum? What about all these other things?

Kanban is about making small improvements so yes, all these things will happen but implement some simples steps:

]]>https://christophelecoent.wordpress.com/2018/10/07/how-to-easily-move-from-scrum-to-scrumban-or-leanban/feed/0christophelecoentDomain Driven Design for Dummieshttps://christophelecoent.wordpress.com/2018/06/15/domain-driven-design-for-dummies/
https://christophelecoent.wordpress.com/2018/06/15/domain-driven-design-for-dummies/#respondFri, 15 Jun 2018 14:57:57 +0000http://christophelecoent.wordpress.com/?p=783It took me a while to get into DDD, wronglythinking it was more an architecture approach that anything else… I liked the idea that the code should be “business-readable” and reflects the way people work or want to work with the application.

After a few years, I hope I have understood DDD:

According to Vaughn Vernon, this is about mining knowledge

It means you must understand how people work and just reflect it into your solution

You cannot develop business applications without DDD any more

Let’s take some examples:

You go to the garage to get your car repaired where everything is done on paper: you get first an estimate, including work to be done, price and your name on the estimate. You accept the estimate, another document, an invoice is given to you. At this stage 2 documents have been generated: an estimate and an invoice:

If somebody puts the estimate in the bin, the invoice is still correct. And vice-versa.

So, in your software implementation, to reflect that behaviour, you have to keep 2 data sets: one for the estimate and one for the invoice: the “estimate” module will provide only copy of the data to the invoice module.

If you don’t do that and share the data instead the invoice module or the estimate module could corrupt the data and you will have no way to know what the right data is any more.

From the example above, the estimate is probably done by the mechanic – they just need the car plate numbers as a unique ID and then the brand of the car / engine type and that’s it. They do not need your data (ok maybe your last name and first name) but they do not need your credit card details!

On the invoice side, the counter will ask you payment method and if you pay by card, at no point in time, your credit card details will be accessible by the garage.

So in your software implementation, “estimate” module will never access customer credit card details and will be given car details and limited customer data only.

The “invoice” module will not store either customer data: a customer management module will handle customer data and will only provide customer name to “estimate” module and “invoice” module. “invoice” module will have to request payment to “customer management” module. And in the “customer management” module, credit card details will be securely stored and encrypted. This is just the way it works without the application: user hides their PIN with their hand.

Communication: the mechanic will go to hand over a copy of the estimate (as said, you keep a reference). The front office uses the copy to create the invoice.

The mechanic is the messenger sending a message to process the invoice. Of course, the mechanic does not know the constraints on the front office: maybe they are about to close for the day; maybe they have a pile of invoices to make; maybe the customer is a VIP… So the front office will organise themselves to process the “message” from the mechanic: the mechanic does not interfere.

So in DDD, we use messages: a message is broadcast to one or more modules that decide how to act on receiving the message: how they react is up to them; this is their responsibility.

I hope these 3 examples just show how DDD is just an adaptation of the way people work and this is not a transformation!

]]>https://christophelecoent.wordpress.com/2018/06/15/domain-driven-design-for-dummies/feed/0christophelecoentLEAN MINDSET goes crazyhttps://christophelecoent.wordpress.com/2017/10/04/lean-goes-crazy/
https://christophelecoent.wordpress.com/2017/10/04/lean-goes-crazy/#respondWed, 04 Oct 2017 10:42:55 +0000http://christophelecoent.wordpress.com/?p=749I have tried to cover all key areas of product software development, from a lean architecture using DDD and a lean UX to get (visual) feedback as early as possible to a Lean IT approach to using Kanban to drive development all under Mary & Tom Poppendieck Lean Product Software Development Principles and sticking in Mike Cohn unbeatable cleverness on user stories.

]]>https://christophelecoent.wordpress.com/2017/10/04/lean-goes-crazy/feed/0christophelecoentLean approach to Product Software DevelopmentFrom Scrum, to Kanban and the Lean Kanban: visual explanationhttps://christophelecoent.wordpress.com/2017/09/26/from-scrum-to-kanban-and-the-lean-kanban-visual-explanation/
https://christophelecoent.wordpress.com/2017/09/26/from-scrum-to-kanban-and-the-lean-kanban-visual-explanation/#respondTue, 26 Sep 2017 10:39:21 +0000http://christophelecoent.wordpress.com/?p=738This is a short description on the key difference between scrum, kanban and lean kanban.

With scrum:

From a product backlog of items, usually user stories, you deliver a potentially shippable increment, made of user stories that are “done”:

The user story arrives in your sprint backlog

We split it into tasks that we may want to estimate in hours (or not)

We implement all the tasks

When all tasks are complete and the product owner has accepted the user stories, then the user story is done: at this stage, we have not delivered any value yet.

We still need to go through the release process to finally delivery your product to customers, that could be lengthly depending on your DevOps process and tools

Only then, the return on investment is triggered.

With Kanban:

We are going to make our workflow explicit making all activities visible. More importantly, we move away from splitting user stories into tasks into slicing user stories into smaller user stories to maintain a flow of user stories.

The user story arrives in your sprint backlog

Instead splitting your user story into tasks, we slice it in smaller user stories because we want user stories to flow smoothly through your workflow: this is a key difference between scrum and kanban

Then, we start working on limited amount of user stories to keep “Work In Process” small and avoid costly multi-tasking

The goal is to go to production as fast as possible for a given small user story.

When the small user story has reached the production environment, then the return on investment is triggered

The speed you are going from the point you start working on the user story to when the user story is in production is your cycle time.

With Lean Kanban:

Keeping the flow-based system introduced with kanban, we look at the whole value stream, from concept to cash, optimizing value delivered to customers, taking a system thinking approach.

We also want to get feedback from customers to make sure we are building the right product and we are building it right.

So:

Upstream, we are going to go as far as we can in our workflow making it explicit we need to get feedback from customers.

Downstream, we are going to visualize the whole product backlog workflow (and that depends how you create your product backlog and manage it: it could be a user story mapping board, a design thinking board etc… As along as this is visible)

Here we are not creating processes, we are just making things visible and explicit as anything implicit could hide issues. Making things visible and explicit allows us to put continuous improvement in place more easily.

In conclusion:

With lean, having an E2E view of our value stream, we are able to optimize the entire system and deliver what really matters to customers: we are interested in the business value I deliver rather than a number of story points.

With kanban, by slicing user stories into smaller user stories and reducing “Work In Process”, we are able to move faster and better.

So, when asking your PO about examples, you want to know the happy path(s), the exceptions (to the rules?). Simple questions to ask your PO giving you the rules around the user stories… So here it is: you can implement each business rule as a user story. An example:

As a school secretary, I want to register a new pupil so I can enrol them in the school

Question and answer: for which school year? this year or next year.

As a school secretary, I want to register a new pupil so I can enrol them in the school this year

As a school secretary, I want to register a new pupil so I can enrol them in the school for next year

Question and answer: can you register a pupil the last day of the current school year? No, only until 30th April. That’s the law!

1. As a school secretary, I want to register a new pupil so I can enrol them in the school this year

Rules to add as user stories:

1.1. As a school secretary, I cannot register a new pupil for the current school year when the date is beyond 30th April

1.2. As a school secretary, I cannot register a new pupil when the pupil is also registered in the school of the region

etc…

Now, you can see the rules can be written with BDD format too. And a BDD “test”, i.e. an example captured during a conversation is a user story: card, conversation, confirmation:

Given a new pupil arrives at school on 1st May

When the secretary registers the pupil for this school year

Then the secretary is informed “pupils cannot be registered in the school for this year after 30th April by Law”

So all I am doing is turning examples of scenarios (business rules) into small user stories. Simple and effective.

]]>https://christophelecoent.wordpress.com/2017/06/01/spidr-and-business-rules-how-to-make-your-user-stories-smaller/feed/0christophelecoentDrop Scrum, use scrumban!https://christophelecoent.wordpress.com/2017/06/01/drop-scrum-use-scrumban/
https://christophelecoent.wordpress.com/2017/06/01/drop-scrum-use-scrumban/#respondThu, 01 Jun 2017 10:50:07 +0000http://christophelecoent.wordpress.com/?p=542I have to a admit: I am an agile coach, started with scrum and got certified in 2008. I focused using scrum and it mostly worked: scrum isn’t the solution but it helps deliver products better than waterfall. I sold scrum and used scrum.

I was doubtful about kanban: not having enough information on how to use kanban instead of scrum in project development. I did use kanban for IT support only.

I had also heard of Product Flow Development.

Last year, for a customer, I thought kanban would be more suitable than scrum as customer requests came coming in and it was hard to plan sprints. To do so, I decided to see what was there in terms of kanban and watched the video of Eric Brechner, Kanban for Project Management: Kanban from Project Management

As I was watching the video, I almost stopped half-way through… Almost but kept watching it to the end where he explains how planning and estimating is done with kanban: I bought his book straight away.

Basically, he is doing proper project management using Kanban… not scrum.

So we implemented kanban with our customers picking up ideas from his book.

Here is my conclusion:

From the first week using kanban, we started seeing real issues and ways to improve

After a month, it was clear kanban does work effeciently

We faced little resistance from the team

It was easy to get the customer involved

Playing with WIP limits (Work In Progess limits), it was easy to improve efficiency of the team, reducing waste and increasing outputs and quality

Culture of continuous improvement was easy to sustain

We had weekly retrospectives with the customers

Other teams started using kanban with very similar results, just a bit of coaching was required

Coaches had to read the book from Eric Brechner and their understanding of kanban was very good. They came up with good ideas.

Even some team members read the book

We used an electronic board making governance of the project easy

So, whether this is called scrumban, lean kanban management, kanban for project management, kanban with some of the scrum ceremonies works very well, and from my little experience, better than scrum!

Here is a summary of what I have collected:

]]>https://christophelecoent.wordpress.com/2017/06/01/drop-scrum-use-scrumban/feed/0christophelecoentLean_Kansan_Picture_2Why agile over waterfall? Learning!https://christophelecoent.wordpress.com/2016/11/20/why-agile-over-waterfall-learning/
https://christophelecoent.wordpress.com/2016/11/20/why-agile-over-waterfall-learning/#respondSun, 20 Nov 2016 19:00:20 +0000http://christophelecoent.wordpress.com/2016/11/20/why-agile-over-waterfall-learning/There are still companies arguing about the good things about waterfall… So I’ll take “being agile” from another angle and will try to prove being agile is just being smarter than using waterfall!

First: where is the problem on any project?

From , https://dannorth.net/2010/08/30/introducing-deliberate-discovery/

“Learning is the constraint”

Liz Keogh told me about a thought experiment she came across recently. Think of a recent significant project or piece of work your team completed (ideally over a period of months). How long did it take, end to end, inception to delivery? Now imagine you were to do the same project over again, with the same team, the same organisational constraints, the same everything, except your team would already know everything they learned during the project. How long would it take you the second time, all the way through? Stop now and try it.

It turned out answers in the order of 1/2 to 1/4 the time to repeat the project were not uncommon. This led to the conclusion that “Learning is the constraint”.

Edit: Liz tells Dan North the thought experiment and quote originated with Ashley Johnson of Gemba Systems, and she heard about it via César Idrovo.

If we assume the only difference is that the second time round you have learned about the problem, this would suggest that the biggest impediment to your throughput was what you didn’t know.

So the problem is: the main constraint on a project is lack of knowledge.

So what is the solution?

The solution is to make learning more effective. So how?

Work on high value and high risk requirements first and don’t waste time yet on low value and high risk:

High risk means lack of knowledge is important (high risk = we don’t know how this is going to work out).

Then high value, low risk

Low value, low risk

Finally, if any money left, low value, high risk: why? Why would you spend time learning on something that has low value and may not be needed at the end?

Request for feedback as quickly as possible: how do you know what you have learned is correct? How do you know you have understand your customers? Learning is effective if first what you have learnt is correct: your customers will tell you. Ask for quick feedback. Don’t delay.

Work as a team:

One does not know everything, communicate as often as possible with your team members and customers (or proxies). You’ll learn a lot from people, not necessarily because they know more but by discussing, they may ask you some very good questions!

Don’t split design, development and testing between different people: make sure same people work on all phases otherwise team members spend time transferring information; spend time sharing information.

Fail fast, learn fast, improve fast: give the team an environment to try and experiment new things. But since we want quick feedback, if they fail, they will fail quickly, learn faster and improve faster!

Be strong on Quality: whatever you deliver, accept it only if it meets your criteria in terms of quality. I am not saying “get it right first time”, quite the opposite. Go fast, get feedback, iteration until quality is right and product is right. Because you iterate quickly, they will get it right quickly and will know how to get right faster next time.

Foster a “learning” culture: books are amazing; some people have a wealth of experience they have captured in books; learn from them so you can quicken learning (from years – for the authors – to weeks – for you!).

And then, use BDD: BDD is asking concrete questions to get concrete examples from your customers. Conversations are the critical part. And the added benefits are: faster learning and understanding of what the right product to build is; set of acceptance scenarios (tests); drive development (and living documentation); and even executable spec (when you automate these examples); etc

If you agree, “lack of knowledge” is really the constraint, then if you focus on learning effectively, you will deliver faster than when using waterfall and also you will demotivate your teams (if you are already using Scrum or Kanban too)!

So, being agile is learning more effectively so hence reducing the main constraint on your project so reducing time-to-market for your product: this is being business friendly… Sooner (less costly), faster (shorter time-to-market) hence higher ROI!

There are lots of prototyping tools out there. I have found Visio to be on the best tools, not only for pure UX creation but as an overall tool to be used from gathering requirements to testing and support.

Benefits of Visio – the tool that goes a long way, depth and width on a project:

When gathering user stories, you can quickly prototype some workflows to confirm your understanding of the user stories.

You can put a few screens and their interactions in on single page having a quite complete view of a specific “theme” (set of user stories that are related).

Visio is part of microsoft offices so companies have already licenses for it and can be installed easily on people’s computer. In other words, you don’t need to go and justify your manager to buy an expensive UX tool.

Visio is great for testing: since so much information is on a visio page, you can just go through each UI element, business rules, error messages to confirm the application matches your visio spec.

Visio is great as a reference to your application for support: functional specs are hard to maintain; visio is quick to update: you just need to see, not to read.

Visio is visual… People are visual

The example below seems complicated as multiple layers are provided… But this example of a true project isn’t complicated. Why? Simply because creating the UX is an iterative and continuous effort. Everybody working on the application is involved one way of the other, including engineers developing the product.