Posts

Capri joins hands with SAP

SAP_logo_4721

We are pleased to announce that SAP has selected Capri Consulting for the SAP Partner Edge programme.  This partnership allows Capri Consulting to provide our clients with access to SAP’s enterprise and business-critical partner solutions. As part of this program, we have joined forces with IIS Group who are an authorized SAP Value Added Resellers.

As a member of this program, Capri Consulting will promote and implement selected SAP and relevant partner solutions, together with IIS Group. This partnership will generate new revenue streams for Capri, allowing us to reach new markets, new client segments, and to accelerate the transformation of our clients’ applications.

SAP Business One is an ERP solution targeted for small businesses. As part of this program, SAP also provides ‘best practice’ industry templates that speed-up implementation while reducing risk and ensuring projects work to budget. The demand for SAP Business One is tremendous and we anticipate customers will benefit from this collaboration.

This membership is a significant milestone in the history of Capri. This will enable our clients to get seamless support from SAP experts. We look forward to extending our successful partnership with SAP.

, ,

Our introduction to Agile course

 

Agile

We’re currently offering an industry leading Agile course…

  •   Don’t miss out on taking part in the UK’s most exciting and pertinent Agile IT course, provided by one of Europe’s leading Agile coaches.

Our next course is…

Introduction To Agile on 6th June’15

In this course, we focus on introducing you to the pragmatic world of Agile development, giving you the basic skills you need as a team member or even project manager of an Agile software development project. This course is suitable for individuals as well as small to large groups, and we can also offer private sessions at a time, date and location of your choosing.

More and more companies are adopting Agile methodology
Don’t get left behind!
Avail 15% early bird discount to all bookings before 16 May’15

Click here to book


AgileManc_FullLogo_Colour_RGB_2015

 

 

Capri 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!!

, , ,

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