, , ,

Welcome to the culture of change

lipstick-on-a-pig

If you’re a manager, whether at middle or corporate level, you more than likely have the power to fire, hire, promote or demote people with very little effort indeed.  You may have the power to move your companies office space to the other side of the city, to change the logo, to make changes to your companies product. Some of these might appear to be stark changes on the surface, but do they really change the company? You can put lipstick on a pig, but its still a pig. You can make as many changes to the company as you want, but it won’t really actually change. After all, your company isn’t your product or your office space or your logo; its your employees. It’s the people. And they’re who you need to change.

No, I don’t mean fire everyone and hire a plethora of new people, I mean change the business culture your current employees have entrenched into them, and everything else will change too.

Professor John Kotter outlines how to go about this in his 1995 book ‘Leading change’. He outlines 8 steps for leading change in your organisation, and they are as follows:

 

STEP ONE: CREATE URGENCY

For change to happen, it helps if the whole company really wants it. Develop a sense of urgency around the need for change. This may help you spark the initial motivation to get things moving.

This isn’t simply a matter of showing people poor sales statistics or talking about increased competition. Open an honest and convincing dialogue about what’s happening in the marketplace and with your competition. If many people start talking about the change you propose, the urgency can build and feed on itself.

What you can do:

  • Identify potential threats, and develop scenarios showing what could happen in the future.
  • Examine opportunities that should be, or could be, exploited.
  • Start honest discussions, and give dynamic and convincing reasons to get people talking and thinking.
  • Request support from customers, outside stakeholders and industry people to strengthen your argument.

STEP TWO: FORM A POWERFUL COALITION


Convince people that change is necessary. This often takes strong leadership and visible support from key people within your organization. Managing change isn’t enough – you have to lead it.

You can find effective change leaders throughout your organization – they don’t necessarily follow the traditional company hierarchy. To lead change, you need to bring together a coalition, or team, of influential people whose power comes from a variety of sources, including job title, status, expertise, and political importance.

Once formed, your “change coalition” needs to work as a team, continuing to build urgency and momentum around the need for change.

What you can do:

  • Identify the true leaders in your organization, as well as your key stakeholders.
  • Ask for an emotional commitment from these key people.
  • Work on team building within your change coalition.
  • Check your team for weak areas, and ensure that you have a good mix of people from different departments and different levels within your company.

 

STEP THREE: CREATE A VISION FOR CHANGE


When you first start thinking about change, there will probably be many great ideas and solutions floating around. Link these concepts to an overall vision that people can grasp easily and remember.

A clear vision can help everyone understand why you’re asking them to do something. When people see for themselves what you’re trying to achieve, then the directives they’re given tend to make more sense.

What you can do:

  • Determine the values that are central to the change.
  • Develop a short summary (one or two sentences) that captures what you “see” as the future of your organization.
  • Create a strategy to execute that vision.
  • Ensure that your change coalition can describe the vision in five minutes or less.
  • Practice your “vision speech” often.

 

STEP FOUR: COMMUNICATE THE VISION


What you do with your vision after you create it will determine your success. Your message will probably have strong competition from other day-to-day communications within the company, so you need to communicate it frequently and powerfully, and embed it within everything that you do.

Don’t just call special meetings to communicate your vision. Instead, talk about it every chance you get. Use the vision daily to make decisions and solve problems. When you keep it fresh on everyone’s minds, they’ll remember it and respond to it.

It’s also important to “walk the talk.” What you do is far more important – and believable – than what you say. Demonstrate the kind of behavior that you want from others.

What you can do:

  • Talk often about your change vision.
  • Address peoples’ concerns and anxieties, openly and honestly.
  • Apply your vision to all aspects of operations – from training to performance reviews. Tie everything back to the vision.
  • Lead by example.

 

STEP FIVE: REMOVE OBSTACLES


If you follow these steps and reach this point in the change process, you’ve been talking about your vision and building buy-in from all levels of the organization. Hopefully, your staff wants to get busy and achieve the benefits that you’ve been promoting.

But is anyone resisting the change? And are there processes or structures that are getting in its way?

Put in place the structure for change, and continually check for barriers to it. Removing obstacles can empower the people you need to execute your vision, and it can help the change move forward.

What you can do:

  • Identify, or hire, change leaders whose main roles are to deliver the change.
  • Look at your organizational structure, job descriptions, and performance and compensation systems to ensure they’re in line with your vision.
  • Recognize and reward people for making change happen.
  • Identify people who are resisting the change, and help them see what’s needed.
  • Take action to quickly remove barriers (human or otherwise).

 

STEP SIX: CREATE SHORT TERM WINS


Nothing motivates more than success. Give your company a taste of victory early in the change process. Within a short time frame (this could be a month or a year, depending on the type of change), you’ll want to have some “quick wins ” that your staff can see. Without this, critics and negative thinkers might hurt your progress.

Create short-term targets – not just one long-term goal. You want each smaller target to be achievable, with little room for failure. Your change team may have to work very hard to come up with these targets, but each “win” that you produce can further motivate the entire staff.

What you can do:

  • Look for sure-fire projects that you can implement without help from any strong critics of the change.
  • Don’t choose early targets that are expensive. You want to be able to justify the investment in each project.
  • Thoroughly analyze the potential pros and cons of your targets. If you don’t succeed with an early goal, it can hurt your entire change initiative.
  • Reward the people who help you meet the targets.

 

STEP SEVEN: BUILD ON THE CHANGE


Kotter argues that many change projects fail because victory is declared too early. Real change runs deep. Quick wins are only the beginning of what needs to be done to achieve long-term change.

Launching one new product using a new system is great. But if you can launch 10 products, that means the new system is working. To reach that 10th success, you need to keep looking for improvements.

Each success provides an opportunity to build on what went right and identify what you can improve.

What you can do:

  • After every win, analyze what went right, and what needs improving.
  • Set goals to continue building on the momentum you’ve achieved.
  • Learn about kaizen, the idea of continuous improvement.
  • Keep ideas fresh by bringing in new change agents and leaders for your change coalition

 

STEP EIGHT: ANCHOR THE CHANGES IN CORPORATE CULTURE


Finally, to make any change stick, it should become part of the core of your organization. Your corporate culture often determines what gets done, so the values behind your vision must show in day-to-day work.

Make continuous efforts to ensure that the change is seen in every aspect of your organization. This will help give that change a solid place in your organization’s culture.

It’s also important that your company’s leaders continue to support the change. This includes existing staff and new leaders who are brought in. If you lose the support of these people, you might end up back where you started.

What you can do:

  • Talk about progress every chance you get. Tell success stories about the change process, and repeat other stories that you hear.
  • Include the change ideals and values when hiring and training new staff.
  • Publicly recognize key members of your original change coalition, and make sure the rest of the staff – new and old – remembers their contributions.
  • Create plans to replace key leaders of change as they move on. This will help ensure that their legacy is not lost or forgotten.

Get in touch:
Our website
E-mail: info@capriconsulting.co.uk
Telephone: 0333-321-8999

twitter | facebook | linkedin

 

 

, , ,

Scrum team failing consistently?

We love firefighters! Don’t we? They are Heroes! But not in software development. In any Scrum software development, very few teams actually manage to find the time to refine and properly compose their stories (user requirements). Because of this, they’re constantly taking time to try and analyse the software requirements during the projects sprints.

This inevitably results in stories being rushed, ill defined, slapdash and careless. This delays the development of the software and  testing, which  should be a major activities, is compressed and squashed into just the last one or two days of the sprint.

And the result?scrum

Firfighting !!!!

The result, is of course, defect in the code. The team then starts firefighting, to try and fix the problems that were born of their ill planning. However, because they’re so caught up in their self-imposed firefighting, they don’t have time to analyse and create competent stories for the next sprint, so they dive right back into the vicious cycle of firefighting.

, , , , , , , , ,

Capri sponsoring Agile Manchester 2015

AgileManc_FullLogo_Colour_RGB_2015Capri Consulting are proud to announce their sponsorship of the Agile Manchester 2015 taking place in Manchester on 7 and 8 May 2015.  Whether you are new to Agile  or have more experience there is lots of interesting content for you with great speakers like Liz Keogh and Jurgen Appelo and 25 sessions, it’s going to be a productive 2 days!

We are very excited for the event to take place, as it is set to be a corner stone of the Agile industry for 2015. It is particularly exciting as Agile has been becoming more and more popular in recent years, with more and more companies adopting the Agile Methodology, of which we are advocates. Book your place now, as tickets are selling fast

http://agilemanchester.net/2015/tickets/

Make sure you come and check out the Capri Consulting stand and collect freebies! See you in Manchester!!

, , , ,

What is technical debt?

Our team is about to go live in few days and we are still discovering loads new issues. Of course frustration is mounting and its getting harder and harder to explain the extra work team needs to do. When someone in the team suggested to go back to the drawing board, my heart sank into my stomach. I did some research, and came across Martin Fowler’s articles man-carrying-donkeyabout technical debt and it felt like deja vu moment. So what exactly a technical debt( or code/design debt) is? The picture on the left describe it very well.

It is:

  1. An unsustainable design that is chosen as a shortcut to make a release. Where the release offers sufficient value to the customer, a PO might accept (or even request) such a shortcut.
  2. Messy or badly written code

The former is a deliberate and prudent decision. The team is aware what is happening and that the design shortcut has to be rectified in the following spring.

The latter is either reckless or inadvertent. The programmers might not be mature enough to know that they are injuring debt (that their code design is not sustainable); we call this inadvertent debt. Or the programmer might not care; then we call this reckless.

Finally, we might only know that we incurred debt after the fact, i.e. we only find out later that our design is not sustainable.

In general, technical debt is a metaphor to explain to POs or stakeholders that there are issues in the code base that have to be addressed in order to keep the code sustainable. Unpaid technical debt means that whenever we want to make changes to the code, we have a bigger effort, because we have to work around the debt. So using the metaphor, we are paying interest and like with interest on a credit card, this can grow to the extent that all our time is used to pay down interest.

Like with a credit card, if we keep using it without paying back the debt, we lose at some point the ability to incur new debt, i.e. we lose an option to cope with exceptional circumstances. It is therefore sensible that technical debt is paid down as quickly as possible.

What do we do in a situation where such debt has become crippling? In an environment I worked in as a coach with an aggressive delivery deadline, the defects were so massive that team was almost unable to make any progress on customer value. There was no way all defects could be cleaned while adding features at the same time. So there was a threat of having a poor quality product by the time the project went live, something the PO and the stakeholders were unlikely to allow. The project was in risk of failure.
To address the defects, it was agreed that the team would do short sprints(1-2 days) until the debt was under control.

A backlog of defects was created and shared with the PO and Stakeholders. Every morning the progress from the previous day was reviewed and the process itself was examined in a small retrospective. Then the work for the day was prioritised and the team would make the agreed improvements.

So every day, a full scrum cycle was carried out. This brought the development back under control and the quality back where it needed to be. In the end, the project was allowed to go live.

In another case with delivery pressures, under inspection it become clear that for a release, it wasn’t necessary to actually deliver a fully functioning version. What the PO was really after was being able to show how the final system would look and behave like to users. The team was able to ignore some inter-system dependencies in the planned release and the PO agree that team would be given time in the following release to resolve these issues.

In this scenario, the debt was treated like features. In cases where work has to be done that is only indirectly related to value the customer can perceive, technical debt can be treated like a story with its own card and estimate. Where debt is an ongoing issue, the team can ask to have a fixed amount of time in each sprint to address debt. This is not uncommon in Scrum teams working on legacy systems.
Learning:

• Technical debt can come in various forms, deliberate or unknowingly. We can be aware we have debt or we might not know.

• Technical debt taxes progress and if not resolved can cripple a project.

• We should pay down debt as quickly as possible.

• Debt can handled like stories and be subject to prioritisation.

• It is good to discuss debt – where we’re aware of it – with POs and Stakeholders so they help prioritise how we pay it down and are aware of its existence.

I suggest team should plan code refactoring as part of sprint backlog. This will keep them on top of technical debts and make code design clean and sustainable.

Happy coding and stay agile.

AgileKrish

Reference:

  1. http://c2.com/cgi/wiki?TechnicalDebt
  2. http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
  3. http://www.martinfowler.com/bliki/TechnicalDebt.html
, , , ,

Agile Tasking

Customer: I want to build a home. Could you give me an estimate?

Builder: No I cannot! You need to give me more information like how many rooms, plot size, how many floors etc.

Customer: I need you to build me a four bedrooms, two and one-half baths, a gourmet kitchen, walkout basement with media room and three-car garage in Pennsylvania.

Builder: Now you are talking! Do you insist on top-of-the-line cabinets and appliances for your gourmet kitchen, or will mid-range ones do? Are you planning to side the house with cheap vinyl or expensive stone brick? Is the house going to be one story, or two?  Will you have simple, rectangular rooms that minimize the materials and the labor required for framing, or unusual shapes like octagons with vaulted ceilings? What sort of flooring, bathroom fixtures and heating and cooling system will you have? Is the lot easy to access, relatively flat and easy to dig, or is it rocky, heavily wooded and uneven?

Similar to above story , its very difficult to provide an estimate when your customer asks the scrum team how long will it take deliver this feature or functionality. Breaking down the user story into tasks will help team to estimate their work accurately and track sprint progress.

What?

Tasking is the process that the developers undertake to understand, design, and properly prepare to write code for a user story.

Why?

The challenging decisions are made during tasking.  If tasking is done properly then the actual coding is a much simpler task.  I believe that this is the most important thing any scrum team does.

Who?

It’s important that all developers and testers attend.  This serves multiple purposes.

  1. every developer on the team begins to become comfortable with the code base for all of their applications
  2. every developer has the ability to include their input on the design and solution
  3. any developer on the team should be able to pick up any story at any point to complete the tasks because they were there and the expectation should be such.
  4. every tester in the team can ensure they’re aware of the solution and that it meets all of their criteria.

It’s also good to have the BA there to review the story with the team and answer any questions.  Once the story is reviewed it usually makes sense for the BA to go about their day and to let the developers get into the technical details.

When?

Second half of the sprint planning session or right before the work is to be done (if  other stories being implemented that may change the approach and invalidate the tasking that was completed).

How?

Step 1: Review Current Code

The developers will review the current code that relates to the user story.  They will walk through the code to ensure that everyone is on the same page with what the code currently looks like.

Step 2: Decide on Changes to Code

The developers will discuss how to modify the existing code to make the addition of the new functionality simple.  It’s common for developers to perpetuate the logic found in the current code (good or bad), so always considering ways to change the code is a key to having well written code.

Step 3: Draw a Sequence Diagram

The sequence diagram is a visual representation of the classes that call each other to accomplish some discussed part of the code.  If this diagram is complicated, then it’s a great indication that the code should be modified so that the diagram is less complicated.

Step 4: Task Out New Work

Once everything is decided, the actual coding tasks should be created and ordered.  Each task should take under an hour to complete.  The developers can then grab these tasks and complete the story in small chucks in separate streams ( if needed).

Why Tasking Doesn’t Happen?

For all of the reasons stated above, it’s important that the teams task stories.  It’s easy for developers to take shortcuts and skip tasking.  One of the main reasons is a lack of collaborative areas.

Tasking can take developers 4+ hours, and they need a whiteboard, projector and computer to properly task.  Finding a room like that for 4+ hours is challenging at times.