Tag Archives: agile

Work fascinates me, I can watch it for hours.


Werk fascineert me, ik kan er uren naar kijken

Werk fascineert me, ik kan er uren naar kijken

“Work fascinates me. I can watch it for hours.” During a gemba, I came across this statement at the back of a Hoegaarden beer mat which was attached to a whiteboard.

Sometimes we are so absorbed by our work that we forget to take a step back once in a while. A step back to observe the process, to observe the work delivered, to look for improvements, to adjust the strategy, …

The disadvantage of not being able to take a step back is that it’s perfectly possible to start working very efficient, doing non-effective (read: non-value contributing) work. Like they say: doing the wrong things in a very efficient way.

Toyota

The rumor is that the ability of taking a step back is one of Toyota’s criteria for acquiring people. During the job applications they leave the job applicant waiting somewhere in the production line/hall for half an hour. Afterwards they ask him what did he see during the waiting time and what could be improved.

Step back, look forward

Step back, look forward. Start, pause, stop. Evaluation. What’s in a name? It are all initiatives to taking the time (and courage) to take a step back and evaluate the current situation and progress.

The challenge is that when times get hard, it’s extra difficult to take the time for this review moment. Nobody has time for a step back moment when shit hits the fan. However, it could help that to build in review moments into your calendar and into the process.

Let’s take a look how Agile did this.

Agile and retrospectives

Agile is an iterative and incremental method used to develop software. (More about Agile in “GAP analyse: Agile projectmanagement en de PMBok aanpak voor kennisgebieden Project Integration, Scope en Time Management”)

In contrast with the familiar waterfall approach, Agile works in bursts. Short sprints of 4 to 5 weeks after which a working piece of software is delivered.

Agile has it’s step back moments build into the process in the name of retrospectives.

After each sprint, the team and customer get together to evaluate their last team effort. What went well? What could go better? It doesn’t matter which technique they use: brainstorming, root cause analysis, … The principle of taking a pause to observe the current efforts and see how the team can improve will positive effects on results, commitment and team mood.

Plan – Do – Check – Act

There’s no use for a step back moment when you’re not taking action. So design a method for assign and follow-up on actions and progress. Use the action list in your next retrospective. See if you made any progress (see also blog entry “A daily sense of measurable accomplishment”) and act upon it when it’s not working.

So, when are you planning your next step back moment?

Tagged , , , , , , , , , ,

Get into flow


FlowFlow is a term used for different concepts. The concept that is described here today is high performance work.

Everybody has moment when time flies by. You are working hard and for some reason, you become unaware of what is happing around you, the music you hear and the feeling of time passing by. You are working hard, you like it and things get done.

For getting into flow you need a lead time: you cannot just start right away with high performing. The lead time is estimated to be as high as 15 minutes, so switching between tasks can have a very negative effect of getting into flow and your productivity.

Here is where the problem lies in many cases at our work and even personal live. Our society is becoming more and more interconnected and next to colleagues asking questions, you now also have cell phone where people can reach you at any point in time by calling or texting. On a smart phone you even have notification for each new email, Facebook request and software update. Your email and agenda client at work (or even at home) is popping up for every new email or calendar notification.

Next to all these, you have the forums, blogs, news sites and communities you are following.

For the digital attention drawers there are some easy tips which you can apply:

  • Put your messenger offline when your dedicated to one task.
  • Disable email notifications on your email client and smart phone.
  • Disable other notifications on your smart phone (eg. Facebook, software updates, …)
  • Only enable reminders for meeting that you have to attend to. Limit the amount and time of reminders.

Team work?

But what about those colleagues that ask you questions every x minutes? You cannot ignore them because the team and team goal are important, but you also can’t devote all of your time to helping them with every question.

How to detect the problem?

First of all, keep your eyes and ears open for complaints from colleagues at the work floor. If you notice there is some frustration, you study it to estimate how big the problem is.

The DILO (Day In the Life Of) technique is a very useful activity study technique for capturing problems like these. Sit next to the employee for one day and capture all actions, requests, meetings, interrupts, … of the day. When he switches tasks add a lead time of, for example, 5 minutes to it and categorize it as non-value adding (waste). At the end of the day add up all the wastes and express it in percentage of time. When the numbers speak, you have a burning platform.

How to handle the problem?

Once you’ve got buy-in, you can start with discussing the problem. Do a root cause analysis to find the real causes of the problem: why are colleagues interrupting your work so much? Or SMARTer: “why are colleagues interrupting my work so I loose 1,5 hours each day by task switching?”.

Typical improvement actions range from coaching, peer coaching, training and mentoring for junior colleagues, product usage demonstrations by business and technical demonstrations.

In extreme cases, you can apply concepts like the cockpit and quarantine. The “cockpit principle” for example is used in the flying industry: during take off and landing the pilots need to be very focussed on achieving success and putting the plain up/down in a safe way. To ensure this the agreement is made not to speak during these critical moments with the only exception when safety is at risk.

In the Agile literature I’ve come across of some application of the cockpit principle where IT workers use flags, mascots and other indicators that they cannot be interrupt for a while, unless for really urgent problems.

But first, let’s look at the root causes before putting on your captain’s hat.

Tagged , , , , , , , , , , , , ,

Lead your team to success with daily huddles



Daily huddles, scrums or stand-ups are means of short interval control meetings. The goal is to line up with the team and set short term focus.

Typically following questions are asked:

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way? 

When introducing daily huddles in teams we see the team running through the honeymoon curve in most cases. In the beginning there is some resistance and team members are reluctant to share. When the team gets more used to it they start to see the advantages and in a later phase the team is actually requesting to do them.

I was watching the movie “Any Given Sunday” last week, so let’s compare it with an American football (rugby) team. The football team, the Miami Sharks, has short and long term goals and a strategy for achieving them. The short term goal is to win to match. The long term goal is to get to (and win) the Super Bowl.

Huddle

Set short term strategy

Let’s look at the short term for now: winning the match. To know if the team is on track for winning the match, a scoreboard is used. The scoreboard is available for display for whole the team, including the coach, the manager and the spectators. There is no doubt about the score: it’s there and it’s real. (For more about team score boards, see “From team planboard to team scoreboard”)

Before the game, the coach (Al Pacino) calls the team together, discusses the game strategy and gives a motivational speech. This way, every single member of the team knows its place and the technique to apply at the field. The motivational speech acts as team pep talk.

The discussion about the game strategy can be compared with a weekly team meeting.

Attune short term strategy to new information

During the game, the team uses a certain strategy, tactics, to get to the short term goal (winning the match). The team strategy discussed before the game can change during the game. The short term goal remains, but the “how” is attuned to game and opponent specifics.

Here we can see these huddles in real live: before a new offense, the coach lines up with a representative high up in the tower which has an overview on the field. Further, the coach discusses with his quarterback  (Jamie Foxx) the plan for the next offence. The quarterback then gets the team together and explains the next steps.

Because the team trusts their quarterback, they commit to the action plan and go for it. When in doubt, they have only seconds to discuss, agree and commit again. There is no time for long talks or unproductive discussions.

This is the essence of the huddles:

  • Keep the end (target/goal) in mind.
  • Attune short term strategy with day to day updates.
  • Hold only short discussions and discuss the essence.
  • Set focus: trust, discuss, agree and commit.
  • Go for it!

The offence huddles can be compared with a daily team huddle.

Attune long term strategy after short term results and evaluation

After the match, the team and coach do a retrospective and watch the match again and again. What worked well? What could go better? Which should be the focus

With this information they can attune their long term strategy for getting to the Super Bowl.

The after game retrospective can be compared with release evaluations and strategic planning meetings.

Tagged , , , , , , , ,

Rational Man day Usage


Efficiency vs effectiveness

Efficiency vs effectiveness

Terms like “Rational Energy Usage” (Dutch: Rationeel Energie Verbruik) are thrown at us every week in the newsletters. They mark the era of questioning our energy usage. Why are we using so much energy and where is it going to? Are our appliances using our limited sources efficiently? Are we using our energy for the right purposes? Unavoidably we get into a effectiveness versus efficiency discussion.

But isn’t the same valid for our man day consumption? Every day a lot of budget (man days) is burned at our companies, but are they spend right?

We make a difference here between efficiency and effectiveness.

Efficiency

Efficiency is doing things the right way, the efficient way. This implies with no overhead and in it’s most optimal form.

An example:

To make your software deliveries efficient you can use fast(er) computers, a customized development system and the Agile methodology.

Improve upon your efficiency with:

  • Eliminate wastes.
  • Check if every employee has access to everything he needs.
  • Check if you using the right tools.

Effectiveness

Nothing so great as doing things so efficient as possible, except when it are the wrong things. No matter how efficient you are working, if you’re doing the wrong things it doesn’t matter.

Hence the term effectiveness: doing the right things.

An example:

If you are developing screens but your customer wants a mobile interface, you are doing the wrong things. It doesn’t matter how efficient you develop your screens, the customer doesn’t need them.

If you want to improve upon your effectiveness, dare to take a step back and ask questions:

Productivity

So what about productivity? Wikipedia uses following definition:

Productivity is a measure of efficiency of production.
Productivity is a ratio of production output to what is required to produce it (inputs).

Productivity is by definition linked to efficiency, but not explicit to effectiveness. So it’s possible to do the wrong things and still be very productive!

Next time when you measure productivity make sure you take this nuance into account.

Measurement comparison

Efficiency

Effectiveness

Productivity

Meeting efficiency (start/end on time, agenda followed, …)Cases of mis-communication per defined and regular period/interval

Cases of re-work due to miscommunication.

Benefits of waste elimination

Meeting effectiveness (right topics/participants/scope)Suggestion system awareness & participation

Feedbacks given after idea processing

Test after training

Discount coupons in regard to coupons spread

Return-On-Investment

Output per worker or hour of labourOutput per hour / day / week

Output per machine

Unit costs (total costs divided by total output)

A little side note with measuring effectiveness: make sure you first define what you want to measure. See that you’re measuring solutions for the root causes instead of symptoms of the problem.

Note to reader: we’ll get a big clash here between efficiency & effectiveness, leading vs lagging, and dealing with root causes 🙂

For example:

When the problem is an increased violence at the streets and as response you’re putting more blue on the streets. You could measure efficiency and effectiveness of the extra police forces, but it’s better to measure the efficiency and effectiveness of the actions you take to solve the root causes of the violence.

Applied to the office context:

If you want to install a performance culture, don’t measure effectiveness and efficiency by measuring the number of participants and participants on time in a meeting, but pick measurements for the performance of your organization.

 Applied to the ICT context:

Software defects need to be solved as efficient and effective as possible, but let’s focus on measuring efficiency and effectiveness of the delivery of quality software.

More on this here: http://blogs.hbr.org/pallotta/2010/11/our-ineffectiveness-at-measuri.html

Tagged , , , , , , , ,

Poker for estimates


Planning poker

Planning poker

There are many different methods for estimating available these days and in “From guesstimate to estimate” we described the importance of them. In the Agile context there’s a popular estimation method referred to as “poker play”, “planning poker” or “scrum poker” that is gaining momentum.

Though I find the name rather childish and even typical for (frustrated) ITers (sorry guys!), the concept actually makes sense.

Often estimating and planning is done by different roles and profiles in the team or organization. But even when it’s the same person taking up both roles, there are the same challenges:

  • How do you know that the estimation is correct?
  • How do you know that the estimator is capable for estimating these assignments?
  • What is the fault tolerance of the estimates made?
  • Are all relevant coworkers contacted?
  • Are third parties contacted?
  • Did he think of everything?
  • Is the estimation applicable for everyone in the team or only for the more/less experienced ones?

Typical results of bad estimates are:

  • The project goes over time, over budget, over scope and/or below quality.
  • Planning needs to be adjusted during the project.
  • Team members complain that the estimates are not made correct.
  • Team members with different experiences levels cannot deliver in the estimated time.

So how can planning poker help?

Planning poker

Planning poker is used before each Agile sprint to estimate the size of the user stories that need to be created. Each team member can give his estimation and for each story the estimations are discussed in group.

The advantages of planning poker are:

  • Each member of the team participates and give his estimation.
  • The initial estimates are made independent (not in team). So the team members don’t influence each other.
  • The individual team members can explain how they got to the estimate.
  • The blocks to estimate are small enough so they don’t need a long prestudy.
  • It will come apparent when there’s not sufficient information available.
  • The power of the group is used to get to one estimate.
  • Extreme differences can be discussed in group.

The best about planning poker is that there is a consensus and commitment reached with the group. Afterwards colleagues won’t complain that someone else created an incorrect estimation.

How can i start?

Would you now need to buy the official “poker play cards“?
No, let’s keep it real and professional. A pile of Post-Its and some black markers would do just great.

This website can help you with a full explanation and some best practices:

http://agile.dzone.com/articles/introduction-planning-poker

Tagged , , , , , , , , , ,

From push to pull for task assignments


There are different ways for creating plan boards (see also “From team planboard to team scoreboard“) for ICT teams and these are dependent of the development methodology that is used (eg. waterfall, V-model, Kanban, Agile, …).

In many cases, the risk exists that the number of assignments for one team member (or more) gets out of hand. You can see this for example by the many Post-Its on the plan board in a typical “to start” or “busy” column.

There is a solution for this and it’s called Kanban.

Kanban

The word “kanban” comes from Japan and means “card”. In the early days of Lean (manufacturing), one referred to kanban as the visual trigger for pull systems. An example from today is a colored marking of the last cigarette rolling paper you take from the role. Today, the word “kanban” is used in many contexts.

In short, the Kanban we described today is an method for ICT assignments that:

  • Divides large assignments into manageable blocks.
  • Makes the workflow visible (which can be as easy as: ToDo, Busy, Done).
  • Limits the number of work in progress assignments (for each team member, for the team, etc).
  • Measures the cycle time of each assignment with as goal optimizing the process flow.

Henrik Kniberg created a good and easy readable guide for it which can be found here: http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

The Kanban system Henrik describes uses also a pull mechanism: assignments are put in a “to plan” column and after the ICT team member completes his assignment and gets a free slot, he can “pull” the assignment from “to plan” into “busy”.

In this blog entry I would like to take a closer look at the pull mechanism behind Kanban when we apply it to getting assignments from the related business party, ie. the customer.

Push

In a push environment, the related business party would push the work to the ICT team. For example, for release X you have to create #Y websites. The ICT team gets the whole assignment at once and it’s not clear what the priorities are, nor what to do first and next. The pitfall here is to work at multiple or even too many assignments at once, and deliver no full scope at the end of the release.

If the ICT team uses visual management, the whiteboard would look something like on the image below (picture from “Agile principles in a maintenance environment” (NL). This can be very demotivating for the team members who see a buck load of tasks coming their way.

Team plan board

Team plan board

Pull

If you can related to picture above, a first step you could take is making separated columns “to plan” and “priority”, and limit the amount of possible assignments per team member. Together with the team you can select on a regular base which assignments get priority and move from “to plan” to “priority”. When a team member has a free slot, he can take up a task from the “priority” column and start with executing. But we can go a step further with pulling and integrate the Voice Of the Customer (VOC).

With a pull mechanism, the ICT team will have a limited number of assignments on their whiteboard. The team members will only have these assignments and no other stuff to worry about. But how can the customer give his input regarding priorities?

One solution I came across was to create a plan board for the customer too. The customer (or the product responsible) can use the plan board for picking priorities for all the IT stuff they want to get created. These priorities can change during the release period, but that’s discussed in the customer team. On a regular base, the ICT team meets with its customer and goes through the new batch of high priority assignments.

From push to pull

From push to pull

This approach has the advantage that the customer can change priorities during development and ICT team members get less stressed when not all assignments are dropped at once in their ToDo box and have clarity regarding priorities at all times. By meeting on regular intervals, the ICT team attunes more with the customer and the customer has the guarantee that the ICT team is working at the right assignments, ie. doing the right things (which leads to more effectiveness).

Tagged , , , , , , , , , , , , ,

A critical path for Agile software applications


Teams changing from waterfall development to a more agile approach are often struggling with the iterative and incremental development. Agile software development can be compared with building a pyramid. If you build your pyramid with the waterfall model (the classic way), the chance exists that the pharaoh dies before the pyramid is completed. If you build your pyramid on an incremental and iterative way, no matter when the pharaoh dies, he will always have a pyramid. The pyramid will not be completed like planned, but at least he has one.

Agile like pyramids

Agile like pyramids

The mindset/rule here is: make sure that if the project ends earlier then planned, you have at least something to give to your customer.

In practice

How would you do this in practice? Let’s say you have to develop a chain of screens with an interface to the backend (database, mainframe). For example a web store.

If you would apply the rule described above in this situation, at any moment in time, you need a partial delivered application which your customer can use. With a chain of screens is more difficult to stick to this promise. You cannot start with building your first screen and, when finished, the continue with your next.

When we look at the teachings of project management, we can learn that the critical path describes the longest path of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer. If we apply this principle to our chain of screens that need to be developed, we can select the screens on the critical path of the application: which screens (and according mainframe interactions) need to be finished first? When priority is given to the development of these screens, we know that in case of project mayhem the customer will have a solution he can work with or further develop.

What about work preparation, prestudy, analysis and design?

The principles of iterative and incremental work can also be applied to assignments other then actual software development. If you would need a prestudy, you can also execute it on a iterative and incremental way. The same applies for your analysis.

In this case, if the pharaoh would die earlier then expected, you would only have the blue prints of the pyramid. You cannot bury him, but let’s be honest: you have to start somewhere.

Tagged , , , , ,

GAP analyse: Agile projectmanagement en de PMBok aanpak voor kennisgebieden Project Integration, Scope en Time Management


Agile Project Management

Agile Project Management – cycle

Deze white paper gaat de kennisgebieden Project Integration Management, Project Scope Management en Project Time Management uit de PMBok vergelijken met de Agile manier van werken.

Eerst wordt Agile kort uitgelegd en vervolgens kijken we naar de oorsprong van Agile. Op één van deze gaan we dieper in: Lean Principles.

Verder worden de verschillende ontwikkelingsmodellen vergeleken en de link met Unified Process gemaakt.

Voor we de kennisgebieden gaan vergelijken, bekijken we ook twee implementaties van Agile: Scrum en eXtreme Programming.

http://karelnijs.be/Projects/WhitePaper_Agile_PM_en_PMBok/GAPanalyse_Agile_en_PMBok.html

Eindconclusie

Er bestaat een algemene aversie tussen de uitvoerders van de verschillende methodologieën. De PMBok probeert vaak (onterecht?) te bewijzen dat ze al Agile werken; Agile probeert te bewijzen dat ze net niet volgens de PMBok werken.

De waarheid is dat Agile in de PMBok past (of minstens complementair is), maar zich ontdaan heeft van verschillende onnodige of te strikte praktijken. Daarentegen promoot Agile dan weer niet cowboy coding door alles toe te laten, maar gaat zelf nieuwe en soms striktere praktijken opleggen.

Verder voert Agile ook de verschillende PMBok activiteiten iteratief uit, maar ook dit kunnen we in de PMBok zelf terugvinden.

The organization and/or project management team is responsible for determining what is appropriate for any given project. – PMBok

Het is het best om uit de verschillende methodologieën de goede dingen uit te pikken en je eigen methodologie te maken in plaats van de one-size-fits-all aanpak.

We merken hier ook een valkuil op: zowel bij de PMBok als bij Agile nemen sommige bedrijven deze frameworks te letterlijk over en laten geen ruimte voor interpretatie toe.

Terwijl de PMBok er op staat om alles officieel vast te leggen, lijkt de focus bij Agile op het officieuze te liggen. Het nut van documentatie en planning wordt erkend, maar er wordt geen tijd in gestoken om deze in dezelfde mate af te werken.

Vaak maakt men ook een planning of een breakdown, maar in plaats van deze in te voeren in de projectmanagementsoftware die vandaag ter beschikking is, wordt het ontwerp verder gebruikt of gewoon vastgelegd op foto.

Vaak wordt onterecht gedacht dat Agile niets van documentatie weten wil. In de literatuur vinden we deze component wel nog steeds terug, maar deze wordt vaak anders aangepakt. Er worden bijvoorbeeld wel tests, high level designs en documentatie voor de eindgebruiker opgesteld.

Tagged , , , ,
%d bloggers like this: