December 30, 2012

I am not lazy, I just don’t like doing it


Do something you don’t like every day.
Visualization, decisiveness, Kanban and consistent will help a lot.
We know that visualization is a powerful tool that helps us get things done. Adding Kanban makes the tool even better, as even difficult things, like doing homework, learning to take exams, going to the gym and so on, once they are on the board, you can’t escape them easily. Even getting your kids to take out the trash or tidy their rooms can be done with a Kanban board. Of course, we parents need to be there to encourage, follow and explain.
But what happens when we need to do something that we don’t like?
We procrastinate. We ‘don’t have the energy’, or ‘now isn’t the right time for this’. Take going to the gym. It’s too hard. I’m too tired. It makes me sweaty. It’s not that we don’t know the benefits – we DO, and we know that we need to do it at least 3 times a week. But we don’t.

Delaying these tasks more than necessary will not lead to a good result. In fact, things will get worse later on.
Dealing with those unpleasant tasks correctly will lead us toward getting them done.
 
It’s simple:  visualize and mark the tasks you don’t like and perform one each day.
How?
1.       Visualize all your tasks using a task board, even ones you don’t like.
2.       Prioritize your tasks. You don’t need to perform tasks that aren’t important, right?

Furthermore, you can prioritize the tasks you don’t like and divide them into smaller, practical tasks later on. It will make getting them done easier. For example: Not all the exam material needs to be studied, right? There are probably more and less important issues there to scope on. Make sure hard learning topics are divided to smaller practical items, so you can pick one topic at a time and get it done.
 
3.       Of course, looking at the positive aspects of the task, even if you don’t like it, also makes it easier. Once the task is higher up the priority list, it is easier to understand that it is important and has value for us…Find what is that you like and make sure to add it to your list as a task as part of the area of dislike. for example: Going to the gym I like  ________ And dislike______
 
4.       Think of creative ways that will help you address those tasks you don’t like, like studying for your next exam with a group of friends.
 
5.       Mark those you don’t like to do .

 

Use different colors to distinguish between regular tasks and those you don’t like.
 
6.       Every day :
a.       Pick up one task you don’t like. Only one, among all the other tasks.
b.      Schedule those that you don’t like into your routine and visualize them. Yes, plan to go to the gym; plan to study; visualize it; write it down if necessary and make sure you do it.
 


 
7.     Consider it as an obligation, a job.
 
8.     Be decisive. Just do it!

 
Further read on the subject in blog:
·         Achieving goals with agile
·         The Power of Sticky Notes
 

 

 

 

December 20, 2012

On our way (Burn) up! - Part #2 -A burn up chart process example:

Let’s go further into a  leads to opportunity example using a burn up chart: (you can read more about how to manage leads and opportunities using Kanban)
      Understand your flow
We need to first review the progress behind the chart
For example:  a lead to opportunity process.


At the end of every week, we will track the amount of contracts signed.
We can track other process areas as we will scope over them if we want to improve in those areas as well.
      Visualize your flow.
 

 
      Visualize the burn up chart. The burn up chart visualizes the progress over signed contracts each week.
 
 
      Analyzing the burn up chart allow us conclude and change.
For example: as a marketing team member or manager what flattened the chart? Was it a seasonal trend? Maybe we didn’t invest in the correct leads?
What made it go up again?
Visualizing the process behind the results will lead us towards better effectiveness and efficiency. We may ask, what do we need to change so the graph will go up again?
 

      In fact, we can also compare our current status to our monthly goal (and we should!)
Obviously we should set our goals according to business needs. The ability to visualize this way is a great motivation tool for the team to reach toward the goal, to be scoped daily over the goal as long as they discuss the  ability to change towards the goal .

Goal missed-- >

 

      Change & inspect
Remember, small frequent changes are better than an entire flow changes, try small process change - then change again if needed.
The change reflection may be immediate shown on the chart.
      Daily meeting:
Meet every day as a team, reflect over your progress and change if needed.
      Retrospect:
Once a week, a sprint or a period of time, retrospect over your performance.
What did we do well, and what can we improve.
The Agile framework enables us to build a continuous improvement mechanism. Obviously continuous improvement has a lot more than just a burn up chart and a flow visibility, but the burn up combining with those Agile methodologies is a one hell of an incentive towards improvement.
There are many more ways we can use burn charts in our day to day life , school , personal projects… but this is another blog story…
Ho … and as always, don’t forget to have fun…
 
For further read and references :

December 13, 2012

On our way (Burn) up! - Part#1: It does not mean the burn down chart makes us go down.


A burn up chart (not to be confused with the burn down chart) is a true motivator for getting things done. It enables us to see our progress, it provides quick feedback that allows decision making, and you can quickly see if your decisions were efficient and effective. Behind the burn up chart lies a process, of course, and our performance is reflected in the chart. Using the burn up chart with Agile enables one person, or a team with a common goal, to continuously improve over things that needs to be done.
Burn up charts are widely used in software development Scrum teams to reflect the release status as compared to the changed release scope.
But the truth is that it is an awesome tool for personal improvement.
So what IS a burn up chart?
A burn up chart is a graphical representation that tracks progress over time by accumulating functionality as it is completed. The accumulated functionality can be compared to a goal, such as a budget or release plan to provide the team and others with feedback. 
The X axis:  Represents time (days, sprints, weeks )
The Y axis: Represents the accumulated functionality completed over that period of time (stories, value or cost).
Every period of time (X axis) we track the progress work completed over our functionality (Y axis)
For example: For an orange factory, we ship orange crates. Every week, we add the amount accumulated to the chart at this week point in time. Now obviously, behind the ‘shipped orange crate’ item there is a process that needs to be followed.
What’s the process? in this case:
Pick the oranges Sort Clean Pack Transport to the warehouse load the trucks Ship Reach destination.

 
The way the factory performs this process effectively and efficiently will be reflected in the chart final outcome points. The chart is just a reflection of a process performance.
 

 
So what’s the difference between a burn DOWN chart and a burn UP chart?

 
And now in detail.
The burn down chart:
 

When we do have a fixed amount of tasks that need doing in a specific time frame, a good way to motivate the team can be to follow the amount of work left. Visualizing the progress from one day to another as a team has a good impact toward achieving the goal.
It provides feedback, and earl feedback at that!
Seeing your team’s progress means that it’s far more likely that the tasks will be carried out. We can deal with any impediments that may occur early on, and make decisions that will change our work flow as we approach our goal. We know where we stand at each and every step, we know how fast we are progressing, and the changes we need to do to complete it.
 For example: a teacher has committed to finish grading 20 exams by the end of the week. Counting down the work left is a good motivator; it’s like a countdown toward the spaceship or a missile launch.
 

 
The burn up chart:
When our goal is one of completion, even within a specified time frame, and we want to track the progress and the amount of work we can do, we may want to use a burn up chart.
For example - converting leads into opportunities as compared to the monthly goal for the sales department.
In this case, turning a lead into an opportunity is a long process involving many hands and operations. Visualizing the amount of contracts signed is a huge motivator for a team to keep driving towards the goal.
Knowing the rate of change enables us to use the early feedback coming from the chart to take action and project the lines forward in time.
 
So both burn up and a burn down charts encourage teams to get things done.
      We can use each of them on the same project. Each reflecting a different scope or process and each is valuable for encouraging continues improvement.
      They are both visibility tools – and as we know, visibility is a powerful tool in getting things done.
      They both reflect reality as it changes. Reality = the process of work we set to get from point A to point Z.
       They are both dynamic enough to reflect a decision or process change immediately.
 
For example : Yesterday we had a rank of 50. Due to market changes, we made a small change - and that is immediately reflected. Early feedback enables us to review our decisions.
      All of the above acts as good motivators towards success – our ability to see and control the flow of events play a curtail rule here in getting things done.

November 17, 2012

Scrum for everyone! What is scrum In a nutshell ?


Well, I think we already realized that scrum can be used almost for any project anywhere…
So here is a short scrum framework technical description that those, ‘Non IT’ guys may use as well.


Scrum' Is an Innovative Approach to Getting Work Done:
Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.’

 Scrum is based on the following main principles:
  1. Interactive and incremental process.
  2. Team self organized based approach.
  3. Adapting to change.
  4. Cooperation and communication is key.
  5. Adapting and following the Agile manifesto and principles
Scrum is one of the Agile practices, based on implementing the Agile manifesto and principles.

The Scrum framework in a nutshell:

A generic Scrum framework looks like this:




Backlog:  The wish list that includes all the things we need to do, ordered by value for top 5-10 only
Sprint backlog: All those things we wish to do in the immediate next execution time frame (sprint) , ordered by value, divided to operative tasks ,and estimated/sized.
The sprint – A fixed time fame, with a beginning point and an end point , I which we execute the backlog tasks and commit for a quality of delivery.

Ceremonies:
Sprint starts with a planning session: The backlog items are sized, divided to tasks, estimated and the scrum team commits for their delivery.
Sprint daily meeting to evaluate progress and commitment

Sprint Demo: At the end of each sprint the team presents the sprint outcomes and deliveravles.
 Sprint retrospective meeting At the end of each sprint , the team will retrospect over their performance for continues improvement.

Scrum holds three main roles:

  • Scrum Team: responsible for deliver 
  • Product owner: leads the production way, Responsible for return on investment. 
  • Scrum master: facilitate the process



The roles of a scrum framework  :
Let’s start with the Chicken and Pig story:

A Pig and a Chicken are walking down the road. The Chicken says, "Hey Pig, I was thinking we should open a restaurant!". Pig replies, "Hm, maybe, what would we call it?". The Chicken responds, "How about 'ham-n-eggs'?"

The Pig thinks for a moment and says, "No thanks. I'd be committed, but you'd only be involved!"

This story represents two types of team members in the Scrum framework. Pigs, who are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress. Chickens are usually management, project managers and others that are not part of the team. Pigs are the actual team members, who do the actual work.


Pigs can have actual tasks on the task board . The project manager needs to make sure there are enough pigs to perform the job and they are empowered to make decisions. For instance, pigs get priority in the Scrum ceremonies. He is the only one that can talk in the daily session and estimate tasks during the planning. The chickens are only there to challenge him to do so , teach him how to do it, and keep him safe so he can perform and deliver.



The Scrum framework is built from different roles that make sure the framework stands.

The scrum team: self organized team Multi skilled, responsible for the delivery of a working product at the end of every sprint. It manage its own tasks, estimate its own tasks and strategies the sprint so a delivery will be possible. The team best format will be up of 3–9 people with cross-functional skills who do the actual work. They are the pigs.

Product Owner: the product owner is responsible for the return of investment. He represents the “customer voice” (it does not need to be a physical customer) - creates and prioritized the wish list called backlog.
He leads the way, decides on what needs to be done and accept the stories.
Each scrum team should have one Product Owner; it is recommended that this role not be combined with that of Scrum Master or the team manager.
The Product owner defines the backlog , is responsible for writing the user stories (but does not need to write them himself) , accept stories, and the sprint demo is for him. For most cases he is a chicken. Meaning, he comes to the daily session, listen and save his questions till the end.
The product owner is expected to be involved, give and get early feedback and accompany the team with feedback.

Scrum Master : one of the team members, responsible to facilitate the process. The scrum master knows Agile, enforces the rules, and leads the team towards the agile mindset. The SM is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverable. He is not the official team leader but should be a leader in any actions and term.

Manager : He is responsible for the vision. He is an empowering manager and empowers the team to make decisions. The manager is responsible for making sure the team performance fits the organization vision. He is not part of the scrum team. He is a chicken.




Let’s go over the process:

We start with a wish list (the backlog):

Basically, the wish list contains all the tasks that the team needs to do - the task pool. This pool is decided by the business. What do I mean?
If it’s a software project, the backlog will include everything the development team needs to do to successfully complete the project, such as developing new features, new reports, and so on.
In our home, the backlog can include all the things we as a family need to do, such as tidy up the shed, mow the lawn, pay the mortgage, and so on.

Let’s imagine a team of school teachers. The wish list will include tasks set by the Board of Education, and tasks that we think are important, such as Parents day, an active recess, and so on.



The backlog, in it’s initial form, can be very general. It can be a list of all those things that we want to happen. We don’t need to go into great detail. For example, the school teachers’ backlog can include fundraising for the petting zoo and fundraising for extra tuition. Both these needs will be added at this stage, even though it isn’t clear which is more important, and how we’re going to do it.

High level ordering our backlog:

Like any personal or software project, we have a lot of things to do. Let’s take a wedding for example. You need to set the date, food, guests, seating arrangements, and more. We know that detailed planning for six months won’t work. For instance, what is the use of planning seating arrangements when you don’t even know who’s coming and where the wedding will take place. We DO know what our high level building blocks are.

Our backlog should be ordered in such a way that we can distinguish between what needs to be dealt with first, and what afterwards. At this stage, we can understand the value behind each task we need to perform, so that we can put them in the right order for the business.

The order of the tasks can be determined by a number of factors, among them the importance of the task, how difficult it is to carry out, how long it will take, and more.
We don’t have to drill down to specific details, yet. We just need to know ‘enough’ about the issue to add it.




Now would be a good idea to think about the relative ‘size’ of each task. Is it a big one, a medium one or a small one?

User stories:

This backlog is then divided into smaller portions, in a process of continuous planning. Don’t forget to do this only with the most important items in your backlog.




User Stories will be created to identify small practical “can do” items. The user stories are a description of a task we need to do, along with a definition of ‘Done’, so the team will know what is expected from them to achieve, be able to estimate and then commit to the achievement of a specific user story or a bunch of user stories.

Each user story will be written in a way that the team will understand its definition of done, and will be considered done when the conditions are met.




Take the wedding for example – We want our DJ to have good references from other weddings – when that happens, the user story is marked as ‘Done’.


The sprint :
The team is given a time frame, called “sprint”. This timeframe is two to six weeks long, and is fixed. It has a beginning and an end and includes all those user stories the team is committed to deliver at the need of it.

The team will select and commit to a number of user stories for delivery during the sprint.

At the beginning of each sprint, the team will hold a planning session. In this session, the user stories will be presented to the team along with the sprint outcome vision.

The team will estimate each user story and divide each user story to operative tasks.

The team will discuss their strategy to deliver all the user stories for the end of the sprint.

For example, our teachers’ parents day, can have a task to contact each class parents’ representative and present the ideas. Another task may be to set the date or to collect only feedbacks depends on the definition of done, as decided by the team.

The team then will commit to deliver these completed tasks.






The task board:

The idea is to be able to look at the entire task pool, and organize them in one place that everyone can see - the ‘Task Board’. Now take ALL those tasks, and stick them on the task board each related to a relevant user story. Placing them on the task board means that you are paying attention to them, and you will get to them.




The task board will visualize the way a user story related task need to go from being defined, to being ‘in progresses’ until it’s done.  The team will move tasks along the board to visualize their current state.
Usually this task board holds three main phases: To-do , In progress, Done.







Once a day, the team will hold a daily Scrum meeting in front of the task board and answer three questions.

  • What did I do yesterday?
  • What am I going to do today?
  • Is there anything impeding my progress?



The team will make sure their commitment is on track and if not, the team will handle the impediment and the solution.

The daily standup meeting lasts no more than 15 minutes.




During the sprint, each team member works on one task at a time, depending on their capabilities, completing those tasks one after another. Once all tasks are completed, the user story related to those tasks can then be accepted.


Acceptance  =  The user story answers the Definition of Done.  Each completed user story will be accepted, meaning, reviewed by the ‘customer representative’ and approved.

End of sprint :
Finally: At the end of every sprint, there should be deliverable user stories, preferably all of them.

Keep in mind, it’s better to have 80% done stories then 100% started stories.

Demo session: At the end of each sprint, the team will conduct a review/ demo session where they will present the sprint outcome: the team will review their sprint vision, summarize their sprint achievement and present the main artifacts to their stake holders.

Retrospective session: The team will retrospect their performance as part of the continuous improvement process. They will then analyze things they wish to continue doing, things they need stop doing and things they will start doing, and add two or three action items that will become tasks on the board for the next sprint.




This cycle of delivery continues.





To sum this up : now  it is your turn :

The beginning:
  • Define the roles. : Product owner, Scrum master and the  Team.

Before the sprint:
  • Create your building block wish list.
  • Order a high level priority according to the value expected.
  • Understand the high level sizing of each building block.
  • Divide big building blocks into operative user stories of 3-5 days effort t estimation max.

The sprint
  • Conduct a planning session, estimate each US and divide to smaller operative tasks. days effort max.
  • Conduct a sprint planning session with all the team at the beginning of the sprint.

    • Present the sprint vision.
    • Ask the team to estimate each US.
    • Divide US into smaller operative tasks.
    • The team will plan their strategy to achieve those US towards deliver.
    • The team will commit.
  • Visualize your sprint tasks and US on the task board
  • During the sprint move tasks along the task board according to their actual progress state.
  • Conduct a daily scrum meeting.
  • Accept finished user stories.
End of sprint
  • Demo the sprint artifacts and outcomes.
  • Conduct a retrospective meeting.


 References: