Speed Boats: Beware of Speeding!

Imagine a project with hundreds of people, a lead time in months, few releases a year. You could compare these as large cruise boats or tankers navigating for few weeks in the immensity and emptiness of the oceans and seas and then stopping to ports very far away from each other. While at sea, or during the build phase, contact is difficult, and you are far away from customers and rescue.

For years now, companies have been trying to reduce their time to market […] Continue Reading this post on Scrum.org.

Inspire your Scrum Team

As a Coach, Scrum Master for a Scrum Team it is sometimes difficult to find ways to inspire people and give them a goal to strive for. Most of Scrum Teams have been trained to use Scrum, they have people helping them to apply it but do they really understand the implications of all this?

Team Building

Scrum or not, companies organizes team buildings for teams, project, groups in order to bring people closer for years now. It is not because it is fun, it has a cost obviously, but we do that because we know that successes comes from motivated group of people. So in order to get better outcomes from a Scrum Team we need to give them an idea of what it means to be a high performance team, not just another team.

High Performance Tree

Few years ago I discovered this video from Lyssa Adkins, very simple but extremely powerful.

In only few minutes by drawing this tree in front of your team and explaining them what it means to be a successful Scrum Team you can get them inspired. Then you can talk about all the attributes of a High Performance Team with them and probably discover more. I encourage you to do it, not a waste of time really.

My purpose as a Coach

In the past years I had the chance to support, train, teach and mentor many teams in adopting Scrum and agile practices. I have seen many organizations, departments, group of people with various point of views regarding agile. Most of the time people around are skeptical and doubtful about bringing more agility in their environment simply because it is different than what they are used to. Thankfully after trying it, a large portion of people, even the more skeptical realize that they can’t come back to where they were before. When people realize this that mean you probably have made an impact.

Outcomes

I consider our job as coaches to impact organizations. When we come somewhere we should assess the current state of things around and measure what is changing weeks after weeks. They open new jobs for Product Owners, they hire an internal coach, the workplace changes, many visible signs you can track. Having teams delivering value to their stakeholders is something but that is not it. If you consider your job done when an increment is in production you probably missed the point. Our job is to bring people together, break silos, activate new channels of communication between people who weren’t talking together, give people autonomy, drive them to the path of mastery and create a supporting environment for all those changes amongst a lot of other things.

The Why

I was and still am a .NET Developer. I did many internships during my scholarship, then worked in small to large projects. I was quite happy and an innocent dev until I became team lead and had to spend my day to break down chunks of work for my team, do PowerPointS to justify changes to my client, report to the project managerS, report to other middle management. Lot of new things that made me realize my job would be boring from this time. Frustration was building up until I resigned because of a bad manager.

Epiphany

One day I was getting out of a job and my community lead decided I will go on an Scrum Training for a week. I came back from holidays and went to it with a vague idea of what it was. After a week I was transformed, literally. I loved my job again.

Since then and after years experiencing terrible and successful agile my first objective is to have people having an epiphany and help them realize they can also change things in better around them or at least try.

Why you should consider following a Product Owner training

This article is not for Product Owners as they must follow this training. I want to encourage Scrum Masters, business analysts, testers, developers to think about following this course.

From PSM to PSPO

My agile journey started with the PSM and PSD courses a few years ago. Then I became a Scrum Team member for some time and didn’t feel the need for more training. But when I started to become a full time Scrum Master I realized I needed more tools and practices to help my teams and specially the Product Owner and the organization around. I was facing questions like: how can I order my backlog? What are the key measures to show to management? How do I build my vision as a PO? And many others. Like many I started googling things and did my best to find and forge my tools. I quickly wanted more than that and went for a PSPO training.

Professional Scrum Product Owner

Like the PSM, the PSPO training is a 2 days course. As usual with Scrum.org the content and the structure are perfect and even with few years of experience using Scrum, having a people around sharing their own experiences and techniques is of great value.

Besides that, I came out of the training with a new understanding of the Product Owner job. She or he is not only the person with the vision we all think of. She is the captain, the leader, the beacon of one to multiple teams like a startup entrepreneur. It is a difficult position that needs a lot of support, empowerment, natural leadership and a very pragmatic approach. From the Scrum Team member point of view, you only see few aspects of the job and this is why we lack understanding of this role. For two days you can be in her-his shoes and see what you would do in some situations.

I won’t give you a list of all the practices you will cover but here are some of them: Impact Mapping, User Story Mapping, Key Value Areas through Evidence Based Management. Anyway except if you have a large agile community around you those trainings will bring you more than you think and remember how great was your PSM training experience and you’ll want to go to this one.

The endless talk about quality in Agile Teams

What quality means for Developers (please read Testers, Analysts, Dev, Ops…) in an Agile team is definitely an endless talk. I could write tons of lines about it but I can also tell you that having the discussion is an excellent start. Too many teams rely only on the process and not the practices. In Scrum for example we do not prescribe any engineering practices but the most performing teams are implementing a lot of them in order to deliver a high value product on a long term basis. It’s a fact.

So, how do we define quality ?

If you look at Clean Code‘s first pages you will see this : “The total cost of owning a mess”. Please read it, print it, sign it and display it on your wall. In only one page and one chart Uncle Bob sum it all. We have all experienced this in projects once. When we start compromising the code maintenability to be faster in delivering features. Until it’s too late to fix the mess. In agile projects we call this technical debt. Technical debt is a whole, not only the fact that the code is a mess. In general, when you have some the product backlog is also a mess in general. So, quality is finally a sum of good technical choices taken at every step of the software development. As a team it’s your responsibility to envision your architecture, take time to think of every choice but also admit the fact that it will evolve, move, live.

My Basic definition of Quality

  • A Working Software continuously delivered to Users
  • Good Technical choices implementing a maximum of the quality attributes : extensibility, maintenability, testability, security…
  • No tolerance for bugs in production
  • Being able to manage the debt

Don’t forget the principles !

Back to basis. Do you remember the agile manifesto? Yes you read it once. Now let’s look at some principles we probably forgot that will help us regarding quality.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

In a following post we’ll go deeper in those principles and see how difficult it can be to implement them.

 

Convincing People Series – Agility is everywhere let me show you

When you start working on agile projects you realize the most difficult part of the job is to convince people. You are basically swimming against the tide on a daily basis. Exhausting. But if you don’t have the right answers to their questions it makes things even worse. So let’s try to build ourselves the right discours.

Agility is a part of our everyday life

A lot of things around us are what we could call “Agile”. The foundation of agility is empiricism. You try something you get a feedback and then you adapt to the situation. You simply use the feedback to progress in the right direction. That’s it.

The Hotel Shower

For example when you arrive in an hotel room for the first time and you want to take a shower. You don’t know at this time what will be the temperature of the water coming outside the pipe depending on how you have adjusted the faucet. So you try and you measure the temperature with your skin then you adjust again until you find the right one. This is empiricism !

Now let’s look at the same situation from a different angle. This time in a sequential (waterfall) way of doing things. First you need a faucet that delivers an average temperature of 38 degrees Celsius. You go and ask someone to build one. You install it and then you open it and you realize it is way to hot for you. Back to square one, unmount it, back to your vendor and ask him to change it to deliver water at the temperature of 36 degrees Celsius.

I will let you imagine the time and energy spent across the entire process. Without mentioning the frustration. In this first simple use case it is clear that we need to adapt from what we measure and we need to do it as fast as possible to avoid accidents.

The Traffic Jam

Another example this time with traffic in big cities. Today a lot of roads are jammed with thousands of cars coming in during the rush hours. Now let’s imagine for a second that all the cars and motorcycles would be trucks instead. See how it could turn to be a nightmare ? And now let’s say they are all motorcycles. How much smoother the traffic would be?

In Paris we have a lot of traffic jams during the rush hours and during those hours you can see hundreds of two wheels. This is because most of us realized that it was much faster to go between the lanes with smaller vehicles. Again a simple inspect and adapt process that we applied to our every day lives.

 

So now, just pick a story your client can identify himself in and tell him how much better it could be to change the way his products are delivered. And again keep this in mind : start small.

The Agile Triangle a change of paradigm in selling projects

For decades selling and contracting projects was quite clear for all parties. One side wanted to have what they asked for inside a specific budget while the other side tried to make sure they were reaching a certain amount of margin.

The project triangle between Scope, Time and Money was pretty clear and most of the negotiation was focused on Time and Money while the scope was non negotiable. You were receiving a RFP (Request For Proposal) and you were simply replying with Time & Money numbers. Sometimes only with one number : money.

With agile projects this triangle is getting horizontally flipped and now the scope is the center of attention. We still have Time and Money because you still need to manage a budget somewhere. But the good news in this new equation is that you can now introduce the concepts of quality and business value in the triangle. Quality by delivering what you can do with a certain level of quality in the time you have. Value by having to choose between features and thus deciding on what is really necessary for your business.

agiletriangle

So as you can see by simply changing our approach and point of view on this triangle we introduced a new paradigm. This is called Agility. No more, no less.

Now if we look at Scrum we see how we tick every checkbox of this triangle:

  • Time : an iteration of less than a month called a Sprint.
  • Money : a product owner who manages the budget by selecting and ordering what is necessary to build the product in the most efficient way with the help of a self organized dev team.
  • Scope : by gathering needs from users, stakeholders and taking feedback the product owner have all she needs to take decisions on what to put in the product backlog and how to order it.

Next time we’ll see how the product owner can steer the Product Backlog with specific engineering practices.

Connect Power BI to your on Premise TFS

03-11-16-3-13-48-PM Power BI is a powerful tool which allows you to easily build interactive data visualizations from almost any type of data you have. This Microsoft tool can be used as a desktop app, mobile app or directly online. It is free of use if you don’t have a lot of data and quite cheap if you need more. I am not a business intelligence developer and I don’t have a BI background at all still I found Power BI a great way to quickly build my dashboards.

As an agile developer and scrum master I wanted to capitalize on the data we have from TFS and make even more complete dashboard than the ones built in. I tried online with my msdn linked Team Services account and It was so mind blowing that I immediately wanted to use it at work. BUT – there is a but – Power BI does not have a TFS connector for on premises TFS servers. And it’s clearly not in the top of their backlog.

So here is the trick to connect Power BI to your on Premise TFS platform.

  1. Download and install Power BI Desktop
  2. Launch Power BI and in the first screen click on Get Data03-11-16-2-56-10-PM
  3. On the Get Data window choose Database then SQL Analysis Services Database. Then click on Connect.
    If you don’t have rights to query this DB ask for a read access.
    03-11-16-2-48-29-PM
  4. Now enter the Server instance name and click on OK.
    03-11-16-3-04-23-PM
  5. In the Navigator window you can now choose which dimension you want to work on.
    For building dashboards regarding teams I use the Work Item perspective.03-11-16-3-05-26-PM
  6. Now you’re all set to build nice data visualization reports.
    03-11-16-3-10-56-PM

Another post will follow on how quickly build some reports with Power BI.

Release Burnup Chart in TFS 2015

With TFS 2015 you can create and add charts to your team dashboard quite easily. In a previous post I was explaining how to create a simple task burndown chart. So in order to have various indicators displayed on your dashboard we will now see how to create the associated query and add the chart

  1. Go to to your TFS Team Project with your favorite browser
  2. Click on the Work tab, then select the Queries sub tab.
  3. On the left of the Shared Queries click on the mouse over arrow and select New Query.
  4. Create and save the query as shown below :

  5. Just 3 lines with:
    • Area Path : Select the area path of the team you want to monitor
    • Work Item Type : Product Backlog Item as they hold the effort
    • State : New, Committed and Done. You can replace New by Approved if you use it to effectively tag the PBIs approved by the PO to be in the backlog.
  6. Go back to your TFS Team Project home page (top left). And click on the green plus icon at the bottow right of the screen. (mouse over the blue pencil to see it).
    tfsaddwidget.png
    Go to to your TFS Team Project with your favorite browser
  7. Click on the Work tab, then select the Queries sub tab.
  8. On the left of the Shared Queries click on the mouse over arrow and select New Query.
  9. Create and save the query as shown below :

  10. Just 3 lines with:
    • Area Path : Select the area path of the team you want to monitor
    • Work Item Type : Product Backlog Item as they hold the effort
    • State : New, Committed and Done. You can replace New by Approved if you use it to effectively tag the PBIs approved by the PO to be in the backlog.
  11. Go back to your TFS Team Project home page (top left). And click on the green plus icon at the bottow right of the screen. (mouse over the blue pencil to see it).
    tfsaddwidget.png
  1. Select the Chart for Work Items widget and click on Add.
    tfstaskburndown2
  2. Fill the configuration with the following
    releaseburnupstep1

    Select the previously created query and the Stacked area chart type.
  3. Scroll and fill the remaining as below then click on Save
    releaseburnupstep2

    Stack by : State
    Values : Sum of Effort
    Range : Last 12 weeks
    Sort by Descending Value

Congratulations you now have a release burnup on your dashboard.

tfsreleaseburnup

From this basic query you can also create those charts :
Work By Team > Segregate by Area Path
Cumulative Flow > Count Product Backlog Items instead of have a Sum of Effort.

tfs2015charts.PNG

Can a team survive without a Product Owner ? Or with a ghost PO.

As you probably know it already the Product Owner is an essential link for a Scrum Team to deliver high value product increments to the business. This is no secret that a good PO can drastically improve the amount of return on investment of a project. And this is probably one of the most important aspect of the job. This role is clearly a full time job and requires a lot of various skills but sometimes companies and people are not ready for that. Even in the Scrum guide the first line of the Product Owner definition is opening the door by saying :

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

We won’t talk here about the skills required for the job or even try to be exhaustive about what the job is about as this is probably another very long post. Instead I will expand about this particular sentence in the scrum guide definition. Doing so I will tell you about how some of the teams and companies I worked for dealt with those various situations.

We have a PO but he does not give/have enough time for the role

This is what I call a Ghost PO. Usually this scenario happens because somewhere people decided to drop someone from the business in a PO role. That can be a very good idea but a decision like that must be supported with specific dispositions. First this person must be clearly train to be a PO. This can be done internally with coaches or externally in a 2 days training at least. Then the PO must have the time to spend with the team, working on the backlog, be available, talk to stakeholders, gather information from as many people as possible, etc. All of that to effectively give a chance to the project to be a success.

However in my opinion taking someone out of a business role can also be a problem for the company. We are supposed to create value and we are removing someone from a place where he or she is already creating value. That’s why we should really consider the PO role as a new job fulfilled by people with the knowledge and the skills that won’t jeopardize the actual company’s business.

Another scenario is when the PO has the time but is not giving time. That can be fix by the team itself in many ways. Use retrospective to talk to him and let him understand he is an important part of the team. The Scrum Master must talk to him and coach him to really act as a PO. If he is not in the same office space, make him move next to you. Do everything you can to make him feel he is not external to the team and his opinion matter.

How the team can react in those circumstances

Somewhere in the company managers gave a budget for your project to exists. So even if you don’t have the PO you deserve there is a chance to get support to get out of that situation. Your Scrum Master has to take his pilgrim stick and find support for the team.

Work on team’s external communication. Invite as many people as you can in the sprint reviews, draw interest around your project. Keep in mind you need to find people to give you feedback on what you are doing. With more feedback it will be easier to steer the product in the right direction and this is what matter the most after all. Of course this won’t be a peaceful journey and you will have to triage feedback in some ways. But if you want your project to be a success and be happy with what you are doing every day you have to move out your comfort zone. If not you will just have worked for another project that won’t go live.

From what I have seen in situations like that some teams are prepared for this scenario by having a lot of knowledge and skills shared in the team. We are all Developers but some of us have very strong knowledge in the domain we are working on. The sum of the team’s expertise shouldn’t be underestimated and should always be developed as much as possible.

To resume I would say there is no magic and having experienced professionals in the team will help a lot. So Scrum On !