, , ,

What’s the Easter story and why do we have Easter eggs and the Easter Bunny?

What’s the Easter story and why do we have Easter eggs and the Easter Bunny?

Its all about rebirth, resurrection and vitality. We at Capri think that its time to rediscover yourself. It’s time to re-skill, learn, upgrade and become new you. Watch our video to see how chicken little took control its situation this easter and became a champion…so what is stopping you…..click the link to start your Easter Egg-ucation Hunt now!

Happy Easter!

, , , , ,

Top 10 Agile Transformation Quotes

These inspirational Agile Transformation quotes are from on-the-ground practitioners and speakers of the Agile community. We gathered top 10 most popular quotes to share here.

1. “ScrumMasters, please don’t touch the task board. It do not belong to you.” -Michele Sliger
2. “Big egos have little ears.” -Robert Schuller
3. “Listen, really listen to people who disagree with you in order to fight confirmation bias.” -Linda Rising
4. “Alignment enables Autonomy” -Henrik Kniberg
5. “it’s not a testing problem, it’s a design problem manifesting as a testing problem. usually.” -Kent Beck
6. “My advice is to stop emphasizing the Agile Transformation process frameworks and start focusing on the company culture and mindsets.” -Selena Delesie
7. “Every retrospective should be unique.” -Esther Derby
8. “Failure really just means that your system is trying to tell you something – so you’d better listen.” -Henrik Kniberg
9. “When the manager plays the role of ScrumMaster, it’s highly unlikely the Team will ever begin to self-organize.” -Pete Deemer
10. “Trying to speed project schedule by reducing testing is like trying to lose weight by donating blood.” -Klaus Leopold

Thanks to Kirill Klimov for sharing these quotes.

, , , ,

Why use Agile?

So Why Use Agile?

Just read an interesting article “Biggest UK Government Project Failures” by Matthew Hayhow. Today, the mainstream software industry has a poor track record; when it comes to delivering working software on time and within budget. It is widely reported that 80% of all software projects fail. What a disaster!

Source: http://www.softwareadvisoryservice.com/blog/biggest-uk-government-project-failures/

The Top 5 Reasons Projects Fail

When asked why their projects failed, managers and employees cited a wide range of issues. But these 5 reasons surfaced over and over again, as the main reasons why their projects failed:

  • Lack of end-user (customer) involvement
  • Poor requirements
  • Unrealistic schedules
  • Lack of change management
  • Lack of testing
  • Inflexible and bloated processes

Here’s how Agile addresses these problems head on…So clearly, with so many project failing, there’s Ota be a better way. And while Agile may not have all the answers for all the problems, here’s how Agile directly addresses these key issues:

The Customer Is King…

To address the lack of end-user or customer involvement, Agile made the customer a member of the Agile Product Team. As a member of the team, the customer works with the development team to ensure that their needs are met. The customer contributes to the requirements, approves the final result, and, is has the last word when making tradeoffs between which features are added, changed or removed from a release.

Requirements Are Written As Acceptance Tests Before Any Code Is Written...

To address the issue of poor requirements, Agile insists that you write acceptance tests before you write code. As requirements are gathered, they are defined as features containing one or more use cases with concrete acceptance criteria. The acceptance criteria is used to write an acceptance test before any code is written. That means that someone actually has to think about what they want before they ask someone to deliver it! This approach radically changes the requirements gathering process and dramatically improves the quality of estimating and scheduling.

Schedules Aren’t Assigned, They’re Negotiated…

To address the issue of unrealistic schedules, Agile makes estimating and scheduling a collaborative process between the Product Team and the Development Team. At the start of a release, the Product Team estimates the level of effort for a set of features. Then they ask the Development Team to review, revise and provide feedback on the estimates. The two teams work the estimates collaboratively until a reasonable schedule is achieved. Then everyone commits to the schedule and the work begins.

Nothing Is Carved In Stone, Except For The Delivery Date…

To address the issue of lack of change management, Agile insists that everyone embrace change, that everyone be realistic about change, and that anything can change except for the delivery date! In other words, as the product moves toward release, the customer (sitting on the Product Team) can add, change or remove a feature based on its priority and value. However, they have to be realistic. If they add a feature, they’ll likely have to take another one out, in order to meet the delivery date. And, the delivery date is always met.

Tests Are Written Before Code Is Written And Testing Is Automated…

To address the issue of lack of testing, Agile demands that tests be written first and that tests be run continuously throughout the build process rather than waiting until the 11th hour to punt some bad code over the wall; to a helpless test team. Each developer has to write their test first, then write the code to make it pass the test. The test is automatically run any time the code is changed. This approach makes testing the responsibility of everyone on the development and ensures the integrity of the build from the start of the project.

Project management is not a separate activity…

To address the issue of inflexible and bloated processes, Agile integrates project management into the process. The project management function is shared across the development team. For example, each 7 person development team (scrum) commits to a release schedule that they personally negotiate. In addition, the code base automatically generates project tracking information. For example, burndown, velocity and test pass-fail charts are all automatically generated by comparing outstanding tests with test passed and tests failed.

Agile is a profound step in the right direction…

As we said earlier, Agile may not address every software development problem, but it is a very profound step in the right direction. Based on the Agile Manifesto, it makes a serious attempt at addressing many of the key problems with current software development processes by empowering and respecting the people who are part of the process and by taking a pragmatic and realistic approach to the software development business.

To find out how you can become Agile, take a look at our Agile services…

, , ,

A Retrospective

A retrospective

The team were always a little tense, stressed after doing the review meeting, and going straight into the retrospective it was always a little subdued and quiet. Therefore it became important that the retrospective was a time for the team to relax and have a little fun. To create the right atmosphere for the team to be able to be reflective and creative.

In the beginning there was a tendency for the team to rush through the retrospective so that we could get on with the planning. Due to this there was very little reflection and more about ‘going through the motions’ to tick that box in our scrum maturity checklist – which was very much the wrong approach.  Therefore the team did not see the value of the retro. At this point it was necessary to improve the retro and to add value, otherwise the retro could have been dropped all together.

I was given advice to keep changing the way that we did the retro and I found a surprisingly large amount of on-line resources. I enjoyed looking for new and interesting ways to do the retrospective, and the team enjoyed the surprise of what I was going to ask them to do next.

Another piece of advice was to keep track of the actions from the retrospective. In the beginning the actions were abandoned to a lonely section of wall, where we would maybe look at them. The change we made here was to add them to the main scrum wall and at the beginning of each retrospective we would review the previous sprint actions and at the end of each retrospective we would review the new actions and assign responsibilities.

The more interactive the exercises were, I found that we got more out of the team on how they felt about the previous sprint and how they would like to improve the next sprint. Exercises that involved drawing were very popular, but the most popular was the gingerbread man decorating (which honestly had little to do with the retrospective and more about having fun just before the holiday).

Retrospective exercises

“Postcards from the sprint” was very popular for doing the ‘thanks you’s’ and ‘how you felt about the last sprint’. For this you need a plain card for each participant. On one side you write the following:

After team have finished the postcard you mix them up and hand them out to different participants. The team then have to draw a picture that illustrates what was written on the other side. After this everyone reads out their post card and shows the picture. Lots of surprising and funny results and a more relaxing and less intimidating (for the more shy participants).

A good reflective exercise was the “hot air balloon”. Draw a picture of a hot air balloon, with a storm on the top left and the sun on the top right. To reflect on the last sprint: at the bottom of the picture where the balloon was tied down write “what was holding us down/ back”, where the fire to heat the air is write “what lifted us up/ kept us moving forward”. For reflecting on the sprint head; on the storm write “what is ahead of us that is going to cause us turbulence?” and on the sun write “what is going to keep us up and ahead”. Invite the team to write on post-it notes for each of these four topics. Review each of the post it notes and put actions in where appropriate.



A retro on the retro

At the end of each retrospective I would always invite feedback from the team on the retrospective itself, so that I could keep improving on the retrospectives. A quick way of doing it was to ask the team to write 2 – 3 words down on a post it note and put it on the door as they were leaving. Some did not work as well as others, but you learn from it too.

As a final note, a packet of biscuits or sweets always cheered the team up and motivated them!

In summary

  • Food
  • Keep changing the exercises
  • Make it fun
  • Keep track of actions
  • Get feedback on the retrospective



, , , , ,

Agile – How to abuse it?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

Don’t document anything!

– The documentation that an Agile project produces is significantly different from what traditional projects produce. An Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.

Agile need to No planning!

– Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.

Just build something! (without capturing requirements)

– The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.

No control over budget or schedule

– Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”

Developers come from wild west (doing whatever they want)

– The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

If you see any of above signs in your team, it’s time to stop pretending and get real. Its time to seek help from an experienced agile coach. I would like to thank Alan Koch for sharing his thoughts.