Posts

, , ,

Building A Walking Skeleton

This article talks about building a walking skeleton which is widely adopted by the Agile software development community.

Capri recently got involved with a greenhouse project to deliver a digital licensing system for Scottish Environment Protection Agency. There were few challenges such as team members were new to the agile way of working, new technology, new to cloud computing and tight timeline. Habitually team started analysing data model of CRM and building custom entity for storing data etc…….

The problem we have with traditional software development

  • Interfaces with various other systems (including legacy).
  • Teams not delivering working software
  • High risk due to dependencies
  • No early visibility of working software
  • Too many technical stories
  • No business value delivery in early sprints

These results in sprint failure and 

  • Frustration builds up
  • Velocity goes down
  • Project gets delayed
  • Project cost goes up

The simple solution to these problems is to start with building a walking skeleton

As per Alistair Cockburn a “Walking Skeleton” is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

walking skeleton

Building-Walking-Skeleton

  • Mini implementation of the system that performs a small end-to-end function.
  • The walking skeleton is missing the flesh of the application functionality, incrementally, over time the full functionality will be added.
  • Its like building chassis with wheels and a motor which moves and adding body later on.

Not to be confused with Spike or prototype which gets thrown away

There are many advantages of building a walking skeleton first

  • —Upfront design/framework
  • —Quicker feedback
  • —Validate assumptions
  • —Proves architecture
  • —Quicker delivery
  • —Reality check
  • Reduces risk
  • —Manages dependencies

Get in touch with us if you need any help or download our slides by clicking the following link.

building walking skeleton

Happy Coding!

, , , ,

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…

3 key qualities that are a must if you want to succeed with project management

Project management is no easy task. It could cause you to scratch your hair, want to rip out your eyeballs and throw tables out of anger. Due to the nature of project management, there are 3 key qualities you need to succeed. Do you tick all 3 boxes?

3 key qualities:

Communication:

Communication is the number 1 quality every project manager needs, for definite. There is no way around it. Without this vital quality, prepare for a shock. If you don’t communicate effectively to your team, then chances are, your team won’t have a solid idea of what you are trying to achieve with a certain task. This could lead to many issues including a failed project, relationships turned sour, and more baggage.

Communicating with all stakeholders is also very important and should not be left until the last minute. Stakeholders play a massive role in the success of an organization so involving them each step of the way can benefit projects in many ways.

Humility:

This word isn’t thrown around a lot in the project management industry but in my honest opinion, it is one that should get a lot more attention. Going into a project knowing there’s a possibility that the project is going to fail and not go the way its planned is critical. This is because it allows you to learn from your mistakes and find alternative routes and methods to achieve your goals

.

Learning humility not only enables you to improve your morale within your team but also allows you to adapt to new changes within the business a lot faster, which is much more important now than ever due to the new changes in Article 50

Being respectful of the needs of the business stakeholders is another way to show humility as these stakeholders may not understand the limitations that come with using the system. This means they won’t know exactly what’s possible and what isn’t as well as the level of risk associated with performing certain tasks for the project.

Respect:

Linking back to the previous point, having respect for your team can help your project in terms of getting it done at a higher quality and a faster efficiency.  One good mindset to have always is that your team works WITH you and not FOR you. Many people use the wrong mindset when creating and planning projects and this leads to projects failing before it already begins. Always maintain a friendly tone with your team and let them know that you’re there to help. This helps boost morale and help productivity.

Having these 3 key qualities is a must if you want to succeed in the world of project management. If you don’t have any of the above or just a few, focus on trying to learn the other qualities and try implementing them with your projects. You’ll notice a huge difference in terms of work ethic, quality, and morale.

Do you tick all 3 boxes?

Send us a comment below with your experience on using these 3 qualities to enhance your projects.

,

Lightning talk: How to build a high performing team

Krishna Thakur, director of Capri Consulting will be hosting a lightning talk at the Delta Financial Systems on the 8th February 2017 at 6:30pm to 8:30pm. The talk will be about building a high performing team using resources that you have.

 8th February 2017 at 6:30pm to 8:30pm at the Delta Financial Systems 

If you are interested in attending this event, simply click this link and follow the steps. It won’t take more than 2 minutes at the very most.

See you there soon.

-Team Capri

 

 

User Stories – How to write good stories?

User Stories

Recently came across a 20 page long requirements document and didn’t know where to start and what to remember, specially for somebody like me who has a memory of a goldfish. I stopped using those time consuming, long and boring requirements document way back in 2007 and started use cases and then moved to user stories. They are easy to write and understand and best thing about them is “collaboration“. I personally love those user story writing workshops with loads of index cards, post-its, marker and DONUTS. So how do you write user stories?

User Stories:

According to Mike Cohn User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Title: One line describing the story

Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
Scenario 2: …

Here is an example from my recent project at Toyota motors.

Sales Performance ReportUser stories

Narrative:
As a [Sales Analyst]
I want [to see parts sales figures for the current month(mtd)]
So that [I can track sales progress against monthly target]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: BI User login
Given [I am logging in as a BI user]
And [some more context]…
When  [the log in successful]
Then  [I will be taken to sales performance report]
And [I will be able to select month and date or defaults to current month and date]

Hope this helps! Good luck with user story writing and don’t forget to buy donuts (skinny ones for me please!).