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 ;)

Thursday, May 14, 2015

Does one size fit all?

My understanding of what an Agile process should be has always embraced the goal of creating value through software development as early as possible, while giving customers/POs an absolute freedom to change their minds (i.e., requirements) in the certainty that the Agile teams will promptly and appropriately respond to the changes with the occassion of the upcoming sprint planning session.

From the willing to fulfill both principles, it follows that in each sprint an Agile team should invest the maximum effort to deliver end-user,  functional stories; and the minimum effort to make progress in preparing future functional stories by means of technical stories.

However, some technical stories are an inevitable factor in the equation of a software development process, no matter what kind of framework it may be based on. As an example, technical architecture designs, third party software developments, QA techniques, etc. must always find their place in the PI and sprint plans.

But my case today is about those technical stories that come up as a result of the "traditional" mechanisms that usually make up the corporate operation structures; mechanisms such as non-automated procedures to promote the software through the testing environments, with an overall duration that exceeds a sprint time frame.

According to the Agile principles mentioned above, a Scrum team should ideally be able to produce all the software layers involved in any functional story in the course of just one sprint. Still, reality is stubborn, and the team may have to break down that functional story into several technical stories for the inner layers (those transparent for the end-user: back-end, services...) plus a final functional story (the one involving the diverse front-ends), and to plan all those stories in succesive sprints. Obviously, all those constraints limit the capability of the team to optimize their generation of value for their Product Owner.

With this picture in mind, I would tend to believe that the Scrum methodology only fits small organizations, but also hope that SAFe will help us to deal with these restrictions. All in all, probably it's just a matter of eating the elephant a bite at a time! ;)

Friday, May 8, 2015

Your first release? Be prepared!

The Agile Release Train has past for the first time in our organization and we have succeeded in getting aboard on time (so yes!, if you are a BBVA client in Spain, our fantastic new tool to help you keep in touch with your financial advisor will be available on your PC and smartphone very soon, just after a short pilot phase).

Therefore, I can say we were pretty well prepared for all the tasks involved in the release process: we had been able to plan in advance most of those activities, even though we were not very conscious of the detailed degree of coordination required between us and the cross teams (release managers, channel managers, devops, quality engineers...) by the end of the PI. And fortunately such tasks could be carried out by the team during the last sprints of our PI in a wise combination with the incremental addition of new functional features.

In contrast, now we have suddenly found ourselves facing an uncertain future: we can expect (and maybe estimate, but only to some extent) a certain amount of (re)work to be done during this second PI as a result of potential defects; besides, we can also expect some improvements that might come up from the feedback of the early users. But all in all, we cannot either predict or mitigate the final impact of these risks in the final delivery of our current PI.

That's said, I tend to agree that Agile provides you with the most reasonable solution: since the throughput of your team is finite, just add the new stories to the backlog and reprioritize it keeping in mind the value return of each item.

Then, why do I feel less comfortable, less confident than I did at the beginning of the former PI?!!!

Monday, April 20, 2015

Let the team self-organize


I must confess I haven't gone yet too long through the theory of agile, scrum, SAFe and so no. However, after six months playing the role of scrum master I know I want to stick to the agile principle of self-organizing teams as the most powerful tool to come up with "the best architectures, requirements, and designs".

Obviously, this principle may (and probably must!) be constrained by the rules of the organization the team works for; here you can find a good case about this fact, with examples I couldn't agree more with.

However, there may be a risk of excessively narrowing the decision autonomy of the agile teams, specially when it comes to a big company, where they must coexist with the traditional, hierarchical structures in charge of IT infrastructures.

And here comes my recipe: the standards, procedures, methodologies... belong to each technical leader (although they should always be open to a healthy negotiation!). But the way the scrum team complies with them should be just an internal decision, out of reach for external influences.

Frankly speaking, I haven't "cooked" it yet, but promise to keep you updated on the eventual result :)

Sunday, April 19, 2015

Keeping pace with the business team

The PI planning (a.k.a., Release planning) session is a significant ceremony in the Scale Agile Framework (SAFe) that plays a key role as a clutch between the long-term, strategic goals and the short-term, sprint-paced deliveries, providing a framework for the Scrum to prioritize the features that will be released in a medium-term period (usually several months). But probably you already knew this, right? ;)

Well, let me make my case today: that important ceremony might provide you also with a new opportunity to fix/improve one of the most crucial aspects of the scrum development: how to match the pace of the business crew (product owner, business analysts and others) with the production capacity of the developers team.

Software development always occurs once requirements definition is done (remember the DoR?) and definition is clearly a business team's responsability; but software roll-out is usually followed by the monitoring of the clients response, another business team's responsability. These interrelations suggest that you should plan your PI in such a way that definition and monitoring outperforms development.

In other words, during the PI planning you want to ensure the business guys will keep a healthy pace on doing their preparation tasks -business plans, groomings, DoR's...- for the features to come during the new Program Increment... even though the eventual development rhythm goes slower than what  the development team could do!

PS Over time, I hope you and me will find the equation to optimize the resources in both, the business and the technical sides of the Scrum. Any ideas?

Wednesday, April 15, 2015

A rush of adrenaline

I want to devote my first post to one of the most important milestones in the SAFe practice: the PI demo (also known as System demo).

PI stands for Product Increment, and although it clearly relates to each new package of the software that incrementally and steadily keeps making up the application being developed by the scrum team, it also refers to the regular period in which such new packages are released. You can think of it as a super sprint, with its specific planning and wrapping up ceremonies.

In our company we currently stick to a period of a quarter, and last week we could experience the opportunity to share our first Product Increment with the rest of the agile teams involved in our SAFe portfolio. The ceremony was just a kind of rehearsal, previous to the marketing of the application, where the team had to demo the new features developed during the last three months.

I cannot wait for the pilot of our application with clients to kick off, a release scheduled for the next two weeks, but believe me: in the meantime, there are not many rewards to the effort and involvement invested by the team during 5 or 6 sprints than the appreciation of your own colleagues for a well done job.

A major rush of adrenaline!

PS By the way, a very convenient mood for the task to come inmediately after the PI demo: the next PI planning, but this topic deserves its particular post ;)

Saturday, March 14, 2015

A trip from "making" to "facilitating"


With a broad experience of more than 25 years in the professional field of the Information Technologies, it is now the first time I feel the need to put my daily experiences on the record.

During my career I have had the opportunity to play multiple roles related with the software development in the financial sector: from SW Engineering to SW Architecture, Quality Assurance and Project Management. Therefore, I can say I was usually accountable for a specific component of the software developing process, either something tangible like a piece of code, or at least something conceptual like a project plan. In one way or another, I was a maker.

Recently, and thanks to a bold step forward taken by BBVA on creating its Digital Banking unit one year ago, I have found myself facing a new professional challenge: to play the role of a Scrum Master, a fascinating experience that has moved me away from the skills required to deal with software code but is in return enriching my expertise in dealing with teams. All of a sudden, I have become a facilitator.

The point is I feel so excited and passionate about my new role that I have decided to share here with you my thoughts and emotions about this experience.

Please, stay tuned! :)

PS jfyi, I am now part of a team in charge of developing the new tools that will improve the relationship between our clients and their personal financial advisors through remote channels (you can take a look at the BBVA Contigo service here ;)