Day 0. As your company is growing there is a rumour about a new project coming into your company – and you need to invest in a software project to make it possible… Maybe you are the one who initiated it. Maybe it is a greenfield project. Maybe it is an addition to an already existing system. Who knows, it may be you, who will be in charge.
Maybe this is going to be your first project. Maybe you are looking into how to approach this new project better than last time. Whatever it is, we would like to provide you with our sincere care by sharing our knowledge and experience.
Definition of Bespoke Software Development
So let’s deep dive in. Bespoke software development is one that focuses on providing a need-specific product to each client. Pay close attention to the wording here. We all know that what we want often may not be what we need. There is also this great amount of uncertainty that you always have to work out. Only if there was a process to guide us in this quest! And there is.
Agile Software Development
Ah, then you remember – agile. This fancy term that everyone in the tech industry throws around and brags about. If only we could do this new project and make it the agile way, wouldn’t that be nice? To achieve that, we need to understand what Agile stands for. We need to know our KPIs so that we can evaluate if we are headed in the right direction. Are we doing the right tasks the right way at the right time in the right order?
Purpose, Value and When to Use Agile
“Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in an uncertain and turbulent environment.” – the Agile Alliance
The term “agile” was introduced in order to clear up what was important for the approach to the original authors of the Agile Manifesto back in 2001.
Why Agile?
Using an agile process gives us the opportunity to time-box the efforts and have frequent feedback loops that are so critical for the process of learning. And only through learning are we able to survive, evolve, thrive and create a better future – and a better product. We are able to start differentiating between what we want from what we need.
Roles
Day 1. The crusade begins. The search is vigorous. The time is limited. The criteria are going through the roof. Who should I choose to be the people in my team? How do I know if I will make the right decisions? Choose the right people? There is the only reliable way – ask your gut feeling.
Have you heard about the partnership structure evolution? No? Let me show you:
- Level 1: (Stakeholders <-> Developers)
- Level 2: (Stakeholders <-> Team Lead <-> Developers)
- Level 3: (Scrum Master <-> (Stakeholders <-> PO <-> Developers))
- Level 4: (Partnership Manager <-> (Scrum Master <-> (Stakeholders <-> PO <-> Developers))
Different organizations operate on different levels that fit their needs, however, there is always room to grow and improve.
Partnership Manager
Day 7. As a business owner, when you make the decision to embark on creating a brand new software product you should start with scouting out prospective partners. Once you have your shortlist, it is time to take your pick. The one that will take care of your business as if he is taking care of his own. The one that will take care of your people as if they were his own people. Does it sound right? It should.
Because it is only when looking for our partners’ success first, can we also be successful. You need to find a person from that one specific company that will make everything click. It is particularly important to make sure that the goals and approach align so that the partnership can thrive.
Scrum Master
Depending on the urgency here we are already around day 14 of our quest. Once the right partnership manager is in place, all things tend to fall in place easier. The first person you are looking to appoint will be the scrum master. He will be the one to lead the team through.
He will be supporting the team by guiding the work process and protecting from external negative influences or any major challenges to the goals of the team. Yet, he has no management authority. Your expectations will be that he really understands all the values and principles behind what makes the agile process really efficient.
Development Team
The scrum master upbrings trust in the developers. You continue to interview programmers in order to make the final decision regarding who will be on the team. For the best result, you want to interview them one by one. In theory, the team should be between 4 and 9 people to be productive.
In practice, from my experience – it is best if they are between 2 and 6 people for optimal performance. You should determine if they all combined have the needed experience and knowledge in order to complete the project. You are looking for a team with various, yet complementarity experience and skills. The team also needs to be self-organizing – able and willing to overcome unforeseen obstacles together with you.
They will be the ones who will be helping and guiding you along the way to uncover the truth, to separate the business wants from the business needs and to spot any new opportunities.
Product Owner
You have your team together. What’s next? When it comes to your organization, how will you fit this new software development process? It needs to be in alignment with the already existing schedules, processes and responsibilities. It is probably around day 21, and the chosen development team is already eagerly looking forward to starting work on the project.
You, in due time, will be looking for the person within your own company that is suitable to be the Product Owner. This person will be ultimately responsible for the direction that the project takes. The one that has the vision to empower and motivate the others. The one that has deep enough understanding of the business and at the same time will be available enough for the development team to assist them with knowledge and experience.
You must choose. Maybe you would be the best fit for the role?
Process management
Daily meetings
So after a month of searching and setting up the base for the project, we begin production. It is week 5 and we have our first daily meeting, we are aligning our priorities and main goals. Maybe we need some business domain introductions from the business experts at the company of the PO. Maybe we need VPN access.
At any meeting there are 3 things that need to be covered – what did we achieved since the previous meeting, what are our immediate obstacles and what do we plan to do (for the day).
There are a few subtle but key agenda points to go through for this meeting to be effective.
- The first one is preparation. A professional and responsible attitude is that everybody is prepared for every meeting that the team has. The daily meeting is no different, regardless that it is done up to 15 minutes. This is especially important when there are impediments that require research and a decision is expected from the PO to be made.
- Another key aspect is that everybody is paying attention to what every member of the team shares. Work as a team towards common goals. Limit the work in progress, stay focused. Help each other. Keeping focus only on identifying problems during the meeting will help to preserve it short.
Resolving the problems should happen after the meeting. PO is not required on the daily meeting but could be really helpful if he attends. A strategy to enable the PO to be focused in his daily work could be to collect all your questions and ask him during or after the daily meting instead of distracting him throughout the day. All of these were really simple but key things.
Backlog refinement meeting
As with every new project we will need to define what is the work that needs to get done. This is done on the backlog refinement meeting or also known as backlog grooming meeting. The best practice is for the dev team to start working as soon as possible on something. This way they will start collecting practical knowledge and understanding about the business.
In the backlog refinement meeting, the following activities may take place: reading and refining prepared specifications of user stories presented by the PO, prioritization of user stories in the backlog, writing new user stories, splitting stories, possibly even estimating.
Sometimes there could be a separate meeting only for estimation. A rule of thumb is that a user story should be able to fit within one sprint or iteration. The professionally-written user story also has acceptance criteria that need to be described properly.
In order for the meeting to be productive, again, a key aspect is that everybody is paying close attention, taking personal notes, asking questions and providing any helpful suggestions that he come to mind. The ultimate purpose is that anybody from the team should be able to work on any specific task after this meeting, ideally requiring little to no further clarifications.
Planning meeting
Other times teams may not need backlog refinement meetings if they are having longer planning meetings. Once we have enough prioritized work to be done in the backlog we can set goals about what we want to achieve during our first iteration. While planning, we may even want to split the target user stories into smaller tasks. One thing that is to be avoided is assigning tasks to people before necessary. This will prevent the effect of people protecting specific tasks or even being reluctant to help a teammate on his task because this way somebody will risk the “success” of the task that he is “responsible” for. For a 2 week iteration usually, you will need about 3~4 hours of refinement/planning of tasks. Especially at the beginning of the project, it may be a bit longer.
So the iteration starts and everybody codes happily. And everybody has one very specific goal – delivering a potentially shippable product at the end of the iteration. A single iteration or sprint lasts usually about 2 weeks and includes all development phases. The timespan may be anywhere between 1 week and 4 weeks based on the needs for adaptation, or stability and clarity of requirements.
The development phases include more or less: requirements elicitation, requirements analysis, requirements specification, feasibility research, design, implementation, documentation, unit testing, integration and system testing and deployment.
Review meeting
Then comes the review meeting, where the development team demonstrates the achieved goals to the stakeholders. Prerequisite for a successful demo is that all demonstrating members of the dev team have prepared adequately and have scripted scenarios of what they are about to show.
Usually, it is a good idea that only user stories fully covering the definition of done are demonstrated. This means that the software is properly tested and fully complying to the acceptance criteria.
Retrospective meeting
We are closing this loop with a feedback session that is called the retrospective meeting. There, everybody shares what went well and what could be improved for the next iteration. An alternative format for the meeting is the start, stop, continue one. Any action items from the meeting are assigned to a specific person in order to be resolved in the future.
Through providing timely, constructive feedback, the whole team is able to learn, grow, adapt and overcome challenges together. A good idea is to keep a sheet on your desk during the iteration where you can record any ideas or observations that you can later present at the meeting.
I am also sharing an example schedule for the long term that I personally enjoy the most:
- daily meeting (every day, start of the day, 15 mins),
- planning (Monday, the beginning of the day, week 1 – 1.5h),
- backlog refinement (Wednesday, end of the day, week 2, 1.5h),
- review meeting (Friday, mid of the day, week 2, 1h),
- retrospective meeting (Friday, end of the day, week 2, 1h).
With this, week 6 just ended. Now just rinse and repeat weeks 5 and 6 with an updated schedule until the project is complete.
Practices
I would like to mention a few practices for research purposes that some of you may be interested in. They are code reviews, pair programming, test-driven development, test automation, continuous integration, continuous deployment. Another process-enhancing “tools” can be considered to be the definition of ready, the definition of done and the acceptance criteria.
Caveats
Be careful about scope creep. Be careful about changing priorities of tasks during the iterations themselves. Do not abuse the sprint commitment (outdated terminology) if you are using Scrum. This is why sprint commitment was renamed to sprint forecast. The team is not committing that the goals are guaranteed to be achieved.
Also, be aware that developers can “meet any deadline if it doesn’t have to work”, additional pressure helps nobody. Instead, elicit the most honest estimates you can get. Then control the scope. Do not turn the daily into reporting to the PO, this will break the dynamics of the team and process and will lower the attention to what each and everyone is saying during the meeting. Work together, help each other, give credit where credit is due.
Takeaway
Be. Always. Ready. The product should always be shippable after each iteration. The business may not want to ship it because, for example, it is lacking functionality but it should be always shippable and working.
Want to see the agile process in action?
Let’s do it.
Together.
