Agile requirements

Posted on Leave a commentPosted in management
  • Ask teams not to document requirements or describe everything in details. Instead of that ask them to document the decisions they made while coming to an agreement about requirements. It might sound the same, but writing down “why” is more important than “what” because it helps you better understand the product and learn.
  • Documentation has two purposes: communication, and memory. From my (most people will share that i think) experience is that written documentation is a very poor way to communicate. It’s a pretty good way to remember things. And maybe sometimes code is the best way to “remember” things rather than creating a pile of documents which will be outdated in less than a month.

Customer focus is not equal market focus ?

Posted on 1 CommentPosted in management
Being a customer driven and customer oriented is very good. This approach allows you to meet your customer’s expectations. And what can be better than happy customer? 🙂 But there is a question: Is it enough only to meet the expectations?
Probably not. And my opinion is based on following reasons:
  • Fulfilling expectation often means that only current problems are being solved without considering general improvements or innovations
  • It might be difficult to be proactive for solution/service/software provider, since most of the time is spent on current problems
  • Customer requests might be very specific and as the result product might be useful only for the narrow market segment

We must listen and understand customer’s market in order to improve this and become proactive. In other words, meet the desires and the unrecognized needs of the customers, understand customers, and think ahead.

Agile product management helps you to combine you customer and market focus at the end of each iteration or release and make necessary adjustments to your road map with less negative impact to your goals. Let’s imagine two approaches: agile product management and waterfall product management

Waterfall product management

Assume that you decided to start working on you product in January. Of course you had a specific understanding level of your market, potential customers at that moment. You performed market analysis and elaborated requirements during next month and started development of your product. But as soon as you “fix” your requirements you lose your “connection” with the market. And the best thing that you might get at the end of your activity is to meet the expectations of your customer (not 100% :)), but definitely nothing more. So, you depend on your luck here 🙂

Agile product management

If we try to simulate the same project, but apply agile product management approach to it, we will notice that in this case we have more chance to achieve better results. Why?

It happens because you always share your results with your stakeholders. You stay tapped into your market and always rethink achieved results, gather feedback and apply changes according market changes. Another thing is that you provide solutions to existing problems early and get a chance to identify new and different ones. These periodic activities also allow you to gain better understanding of the domain (market/customer and etc) and provide better results in future.

What about real life sample? Well, imagine you develop several custom solutions to different customers. These solutions do pretty much the same thing. After another review (you have enough knowledge about this specific market at that moment) you might come up with two approaches:

  1. just implement another custom solution to new customer
  2. or start working on a common solution, which will meet the expectations of most of the customers and leave custom decisions only as special cases

So in this sample you had to stay customer focused while making a solution to a specific customer, but you must be market focused to make the second decision, since it allows you to attract more customers.

Customer focus is not equal market focus.

 

WHAT and HOW? View from Product Owner perspective …

Posted on Posted in management

There is always a discussion during sprint planning sessions about requirements and design, what and how and etc. It seems to be that difference between WHAT and HOW is not always clear for team members and as my experience shows require exact definition within team. By the way, I assume that it might differ from team to team, due to: team experience, type of specialists within a team, level of product owner input and etc.

I noticed following problems due to different understanding of these (WHAT, HOW) terms, which of course lead to failed sprints (and we don’t want such things to happen, do we?:) ):
1. Product owner and Team have different view regarding sprint input
2. Different understanding of “scope creep” definition – f.ex. If column was forgotten in grid. Is it scope creep and should be moved to next sprint? Or is it just “forgotten” task? I understand that you might answer it depends, but the question remains and might lead to very hot discussions.

Note: These questions should arise and addressed during sprint retrospectives, but these just sometimes don’t. Please refer to post script section where sprint planning meeting is defined by the Scrum book.

In order to avoid problems discribed above I always try to detail WHAT definition in the following manner:
1. Business, market and/or users needs. These things can be measured by return of investment and other metrics that make sense in a specific case. For example, we will gain 10 customers in some country market if we are integrated with billing system X. In other words I call this part WHY, which helps team members to understand the actual value we are planning to introduce.
2. Some initial analysis by product owner (or his analytics team) helps to introduce product requirements (or software solution) – actual explanation of WHAT needs to be done within the solution/system/product scope. This section explains the actual goal for the team, the results to be presented at sprint review – it can include mandatory data to be displayed, minimal actions to be performed.

Regarding HOW definition, I expect following from the team:
1. After business goals and actual results are understood, team is ready to start working on high level DESIGN of the implementation.
2. In parallel or after making the design team can move to TASKs identification.

In my opinion all details like which columns should be displayed and which not, how the buttons will appear and etc should be in team’s responsibility and should be included in HOW definition. I intend to call these kinds of “requirements” implementation details rather than product/project requirements.

I have only one strict rule – implementation details can be managed easily by the team (added, changed, removed) unless these actions don’t break WHAT definition of the specific requirements. In other words implementation details should be the first in the line for tradeoffs and should never be treated as scope creep in case if main goal can be successfully achieved.

Summarizing everything above – clarified definition of WHAT and HOW terms help product owner prepare better input into sprint due following reasons:
1. Level of business, feature requirements detalization is defined within team.
2. Better understanding what scope creep is and what “forgotten” task is.
3. Better sprint goal definition and understanding, which automatically leads to better spring reviews (or results acceptance)

P.S. inspired by this post and problems in daily work 🙂

P.S.S. Sprint Planning by the Book
There are two parts to the Sprint Planning Meeting: the “What?” part and the “How?” part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of “What?” Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint.
Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an objective that will be met through the implementation of the Product Backlog. This is a statement that provides guidance to the Team on why it is building the increment. The Sprint Goal is a subset of the release goal.
The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.

In the second part of the Sprint Planning Meeting, the Team addresses the question of “How?” During the second four hours of the Sprint Planning Meeting, the Team figures out how it will turn the Product Backlog selected during Sprint Planning Meeting (What) into a done increment. The Team usually starts by designing the work. While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day. This task list is called the Sprint Backlog. The Team self-organizes to assign and undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint.

 

Integrations with 3d party systems: what not to forget

Posted on 1 CommentPosted in management

I am leading integration projects recently, so decided to look for best practices of what must be done/clarified to make integration successfull.

Accidentally i was given a book to read – Software Requirement Patterns (Best Practices) by Stephen Withall

In Chapter 5 there is an overview of what is important for integration projects.

All integrations have following main issues:
– systems cooperation might be time-consuming and unpredictable undertaking
– interfaces for other systems might be very complex
– if external inteface is used, it might not do exactly what we want or might work as we expected
– if we are developing own interface, we become dependent on other system to implement it properly
– and of course testing becomes more complicated, since not all problems are identified so easily (communication, technical and other issues)
– all upper issues become even more difficult to manage if both sides are working on integration at the same time

To manage integration more successfully we should define requirements for inter-system interface this way.

Interface requirement
1. Interface name – meaningfull name
2. Interface ID – unique number within the scope of the system
3. The system at each end – it might be that the same interfacw might appear more than once, so it needs to be explained
4. Interface purpose – self describing 🙂
5. Interface owner – describes which organisation is responsible for a certain interface
6. Technology to be used for interface

Extra interface requirements
Individual types of interaction; Throughput; Scalability; Extendability; Availability; Traffic verification and recording; Upgrading; Security; Documentation

Considerations for Testing
1. Explicit interaction requirements
2. Implicit interactions, which help to satisfy goals stated indirectly (f.ex. security requirements might involve additional kinds of interactions)