Sunday, February 7, 2016

Applying Inspect & Adapt to the product

Here you can find my last contribution about how to help your business colleagues during the adoption of an Agile methodology in a big company. It comprises a couple of ideas to get the most from Agile and ensure the product really fits the customer needs.

1. Embed metrics and feedback as part of the MVP
These are practices that are far from being mainstream in the corporations nowadays, mainly because the traditional software production framework gives no agile options to improve a product once it has been deployed. The business guys are more accostumed to rely on manual techniques, such as surveys, to grab information about the usage of the product and the degree of satisfaction perceived by the customers or final users.

So it's time to assist our Product Owners in changing their mindsets and in being prepared to deal with the reactions of the end-users optimally, by making use of the mechanisms provided by the Agile framework such as the product backlog prioritization. Work with them to come up with a strategy to learn from the usage of the product and adapt to the needs of the user, ensuring the mechanisms to provide with that information are part of the Minimum Valuable Product.

2. Allocate buffer to analyze the outcomes
Finally, the business staff that comes from traditional frameworks have adapted themselves to a cycle of definition, development, deployment and operation of the product, with all these activities being carried out in sequence, and being the analysis of the outcomes part of the operation.

Now, they will face a framework that entails the concurrency of those activities, once the product has been delivered: since the very moment the product has been deployed the Product Owner is responsible for analysing outcomes such as the response of the user, the value creation, etc.. But she still keeps her responsability for defining the features to be part of coming iterations, and this is a working pattern she is not prepared to.

So, it's responsability of the Scrum Master here to assist the business guys in forecasting and estimating the time they will spend with these activities in future iterations, so that they make room for all the activities expected to be done as well (definition, refinement and testing).

We want the framework to be sustainable, but this point takes us to the potential issue of the right balance of business and technology staff within the team, which may vary significantly as the business guys get involved not only in tasks related to the functional definition and testing, but also more and more in tasks of collecting and analyzing the data related to the usage of the product (metrics and feedback, as mentioned before). But this is a can of worms I will not open today!

Sunday, January 24, 2016

The language barrier

Once again, I will try to summarize here my view on another key aspect to be carefully considered during the transition from traditional to Agile methodologies in the context of a corporation: the sudden exposure of the business guys to the technical language, an inconvenience they may have avoided so far thanks to the shelter created by IT structures like the “IT Reps”.

The relocation of the business members to a site shared with the testers and developers gives rise to the main barrier in the process of their adaptation to living together with the technical tribes. Without their missed “translator” (the former IT Representative), terms as obvious as “backend” or “service” will sound hollow in the heads of the business team the first times, but soon will turn into a concern as they become commonplace in their conversations with the technical guys.

Here, our goal should be to point out the similarities in both perspectives, the business and the technical stuff alike. What do I mean by similarities? While the business guys may take the complexity of the engineering language for granted, the technical guys may well have the same perception of the business jargon; so, let’s highlight this fact, and let the Product Owners and Business Analysts know that the business language may be very frightening for the software engineers. The effort to understand a new language is reciprocal.

On top of that, Scrum Masters must not forget to add a drop of empathy to the formula: all Scrum Masters have an educational and professional backgrounds, but they do not necessarily have to overlap either the computer science or the corresponding business field. That’s to say, to some extent the SM is condemned to be inmersed in (and eventually to command) both languages. His and hers is the highest penalty of all!

Saturday, January 2, 2016

An effective process of definition (II)

Hi, let's keep on going through my recommendations about a health product definition: based on the outcomes of the Design Research, you will want to outline your product by means of a Story Mapping.

Over time this technique has almost become a methodological standard for any Agile approach, as it helps the Product Owner to break the system into epics, features and, utimately, user stories. And when it comes to a corporative context, in my opinion this activity, that can take one or more working sessions, should gather together all relevant stakeholders, which usually represent a good collection of departments: from marketing to legal, from customer segments to operations, from business processes to customer service. Thus, we will come up with a comprehensive, though high-level, picture of the new product being defined, through a process-oriented approach that entails the demands of all the end-users involved.

Now it's the time for the backlog prioritization and the selection of the features that will account for the MVP or Minimum Viable Product. From my experience, this is a crucial milestone in the process of setting the foundations for the Agile project to be kicked off. And it's crucial because prioritization is a practice the business team are not accostumed to; their previous experience is just an all or nothing approach.

My tip here: have on hand facts and figures that show the proportion of functionalities that are commonly underused, or even not used at all, in previously delivered products at the company. Remember that in the context of a corporation, typically dozens of sw development projects are ongoing concurrently, and hundreds of applications are available at the desktops, tablets and smartphones of the end-users (I mean, employees as well as customers). I am sure you are already familiar with the commonplaces of those figures (they range from 64% rarely or never used in a 2002 study, to 80% in studies about the Microsoft Word processor); well, you will hardly find more about this on internet, but you do not need magic to come up with the figures of your own company.

That's said, you may not imagine how disturbing they are for the business units when they are confronted with them, because they may haven't been told about them before. We all know that "less is more" but, please, be kind and empathetic: it's hard for the Product Owner to assume the fact that some of the features identified during the previous phases might never be implemented. On the contrary, show her the advantage in managing stakeholders: she can always explain "those extremely important features" will be implemented in the upcoming versions to be released soon.

Of course, during the coming iterations we will have the opportunity to repeat the refinement and reprioritization of the product backlog again and again, and to strengthen this practice. Nonetheless, the first instance of this exercise will teach the Product Owner a lesson about the necessity of handling her product as a living being, that must evolve from elementary to complex no more than what is demanded by the end-user and the market.

Thanks for your reading, and by the way, enjoy a Happy New Year 2016!

Monday, December 21, 2015

An effective process of definition (I)

During my recent talk in the Conference Agile Spain 2015 I addressed the issues that Product Owners at corporations face when they are challenged to join a development team and adopt an Agile methodology.

Based on my experience, the product definition is probably the most painful change for the business guys adopting Agile, since it requires not only a U-turn in attitude and a dose of open mind, but also a boost in skills. I mean, it’s just not a matter of unlearning, discarding and throwing away the traditional models: the whole bunch of requirements upfront, a textual and linear format (ppt, doc…), etc. It also requires a significant effort to develop a new mindset: essentially, the ability to slice the product into features or epics and user stories. An ability which may look natural when you haven’t come into contact with the definition of requirements using traditional methodologies, but that entails an important training to unlearn the old style and learn the new model.

My recommendation here is to advise the Product Owner to adhere as much as possible to a process whose first phase should be a Design Research.

I have no doubt that the guys in the Business Development units of our corporations usally rely on techniques to come up with ideas for the new products and services, but I am pretty sure that those techniques usually belong to the discipline of Market Research, with focus set on creating value for the organization.

In contrast, Design Research focus on creating value for the end user, providing with a powerful opportunity to shape those new products and services to the needs and expectations of the clients, in a "customer-centric" approach. Knowing the clients and even co-creating with them is crucial if we want to fix a viable market goal. Outputs such as insights, customer journeys with opportunities and pain points, conceptual designs like wireframes and so on are all invaluable resources for the Product Owner to define the product.

That's said, what are my advices with respect to this point? First, never skip this phase: it usually accounts for a small percentage of the entire budget the project will expend during the phase of development. And secondly (and most important did it not require number one): make the professionals in charge of the Research to share the results not only with the business guys during the early stages of definition, but also with the Development Team once the Scrum has been formed. You will hardly find a guy in the BusDev unit of a corporation able to beat with her/his numbers and figures the story-telling of genuine, passionate researchers and designers. The goal? Your DevTeam will immediately feel on board at the same level than the PO, removing potential barriers in the communication among all of them during their future discussions about the value provided by each funcionality.

Wednesday, December 2, 2015

Thanks, Three Amigos!

One of my key learnings from my experience as SM if how hard the definition of a user story may become, as it requires an effective communication from the initial intent of the business staff to the final understanding by the DevTeam. A lot of literature can be found around this subject, but I want to share with you an experiment conducted with/by my team in the quest of the "nirvana" for the DoR.

The approach was derived from a fantastic idea by Ryan Thomas Hewitt, named Three Amigos; I guess you need no traslation to this... The idea is pretty simple, but effective: let's pair, if you allow me the expression, the Business Analyst with the Tester and the Developer. Starting from a proposal of description produced by the BA, they iterate to improve such description with a higher level of detail until they all have the same understanding and agree the story is ready for development.

In our own trial, that was sponsored by the guild or system team of Quality Enablement, our initial goal was to ensure a complete alignment between the Business Analyst and the Tester by assigning the first one the task of writing the test scenarios in the BDD format of Given/When/Then. But we took the trial to the extreme of asking the BA to use kind of Gherkin language and to operate a repositoy of scenarios, so that their definition was almost directly applicable to .feature files. Even a website application was built to assist the BAs in manipulating those .feature files, but in a guided environment and insulated from the complexity of purely technical tools such as eclipse.

Our experiment failed, but that was as good as it would have been, had it succeded. We learned a couple of things: you will hardly obtain productive outcomes in the technical side when you ask the business guys to do it.

The second learning was that we were missing the other crucial piece: the Developer. An agreement reached only between the BA and the Tester does not ensure the alignment of the developed feature with its acceptance criteria.

So, we changed our mind with respect to the tool, but also found a simpler way to the ThreeAmigos approach:

  • first, the BA defines the acceptance criteria, describing scenarios, events and outputs but in plain spanish
  • secondly, the BA joins the Tester and the Developer so that they navigate through the full set of requirements and reach a common understanding
  • third, the Tester defines the acceptance tests using Gherkin

I would say this approach is completely compatible with the idea of the 3Cs (card, conversation and confirmation), since all three actions are activated here, but it makes very clear the responsabilities of each role, and furthermore, the accountability of all of them as a team.

Friday, August 28, 2015

Making do during vacation


In Spain summer is the season when most people tend to take their vacation: I would say every team member spends an average of two or three weeks out of the office during the months of July and August.

This fact creates some trouble in the running of the Scrum methodology during that period, mainly due to a couple of reasons:

- On the one hand, the vacation periods usually match one or more calendar weeks, starting on a Monday and finishing on a Sunday, instead of doing it with the iterations or sprints. In other words: developers and business staff leave the team before a sprint has finished, and rejoin it when a new sprint is on its way. In my opinion, only really cross-functional teams have the ability to smoothly overcome this difficulty, since the tasks associated to the user stories planned for each iteration are not pre-assigned to a specific team member.

- On the other hand, it's also time for the vacation of the Scrum Master, a key element in driving the methodology: she encourages the team in focusing on each sprint goals, and assists in solving impediments. So, what to do in the absence of the Scrum Master? In my opinion, an experienced member of the team can temporarily take charge of most of her responsibilities just by following a couple of rules:

  1. Facilitate the ceremonies (plannings, demos, retros, and so on)
  2. Spend time on assisting teammates to remove the obstacles of their blocked tasks
I know: easier said than done, but sure an achievable goal with the help of the team.


As August is coming to its end, my current team has already underwent a couple of months that involved the product increment corresponding to four sprints, and we have done it under circumstances that resemble my previous description. In my upcoming return back to the office, I hope that all our planned actions have proven successful in coping with this unconventional situation!

Thursday, August 13, 2015

Training is a plus


I hope you have noticed my long period of writing "drought". I would probably be in trouble, otherwise ;)

And the reason for this three-month period of inactivity is related to an effort, equally mine and of my company, to improve my knowledge and skills on Agile methodologies through formal training. Basically, I have attended a couple of courses that have changed, maybe not radically, but sure significantly and positively my consideration of my current job as Scrum Master.

On the one hand, I have had the opportunity to go through a SPC course by Scaled Agiled Inc. The course prepares you for the Scaled Agile Framework (SAFe) Program Consultant certification exam, and makes an overall and intense trip into the foundations of this methodology, which, leveraging from Lean and Scrum principles, enables medium-size and big companies to organize their software development around agile teams.

My key learnings? SAFe extraordinary ability to effectively coordinate large workgroups, up until around 150 people, in an incremental and iterative software development with a common goal and scope (agile release trains); and also the appealing simplicity of the budget management in the search of value generation at the level of the portfolio layer.

And my main outcome? Of course, my certification as SPC one week later! :)

On the other hand, I have received a course designed to prepare for the PMI certification in this field: the PMI-ACP or Agile Certified Practitioner, a first-class abridgment that spans many approaches to agile (Scrum, Kanban, Lean, XP and so on), providing you with a comprehensive view of this subject matter and its many flavors.

My key learnings? The common factors and benefits that have led different people to give birth to and to embrace the agile techniques and practices, even with some significant variations in their approaches. In other words, the conviction that the malleable nature of the raw material software engineering works with (i.e., software code) is more efficiently turned into value through agile methodologies.

In summary, I have had the opportunity to feel the robustness and richness of the agile methodologies from an academic perspective and to compare that information with my daily experience. And now I can say that I have found out many opportunities to improve my professional performance just by putting some of those learnings into action.


PS  I hope I will be able to give you good news about my ACP certification soon ;)