Know more and connect with me on [Linkedin Profile].

Sunday, October 30, 2016

Why Velocity is a Broken Performance Metric?

In Scrum, we have two main metrics to measure Sprints. The first one is the Velocity, which is defined as the total story points of completely developed and tested User Stories. The second measure is Burned Effort, which is the total number of hours spent by the team throughout the Sprint. We use Burn Down chart to plot the remaining effort to check our progress daily and ensure we are on the right track, else we are advised to take action.


Velocity is designed to be used as a metric to measure and manage scope of work within a release. It is not designed as a productivity measure that we urge to increase overtime.

Many teams or sometimes managers consider Velocity as a productivity measure and insist that, teams should optimize their work and increase their velocity always. Optimizing engineering work is an acceptable target, but Velocity is has another goal to play. See what happens when teams are urged to increase their velocity overtime:
  • They tend to estimate new stories in larger sizes. So a troy that is used to be of size 3 will be sized as 5.
  • They frequently resize finished stories as if it took more than the planned effort and consider this as a correction.
  • They relax Done Definition. So, more stories are earned even if they are not really complete. You will know just before the release date, when you find a lot of bugs are accumulated and needs a lot of extra time to be fixed. 

This usually shows false increase of Velocity or inflation, where the increase in Velocity does not represent actual increase in value delivered. But managers may feel happy achieving better Velocity over time. Is this misleading? Yes of course. If you are already improving, why you may consider other ideas for improving?!

So, the point is, do not use Velocity as a measure of team productivity, but to manage release scope so that, you are able to track your progress effectively throughout the release.

Optimizing your work in Scrum has a different set of measures and actions, let me highlight some:

  1. Ensure a strictly Done definition overtime through the heavy use of automation. So, each Sprint is producing a really potentially shippable product increment. There are no stability Sprints at the end of the release any more.
  2. Ensure  the reduction of number of test/fix cycles. Testing is valuable, but too many bugs are a waste that switch our focus from learning to write better code first time to expensive cycles of test-fix-retest. 
  3. Ensure you finish almost all stories planned in the Sprint and avoid partially done stories that are moved from Sprint to Sprint.
  4. Reduce Sprint timebox over time. As example, if you started with a Sprint of 4 weeks then optimize to switch to a 3 weeks Sprint, then to a two weeks Sprint, etc. Agile prefer shorter cycles. Per second Manifesto principle: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

Finally remember, Velocity is a metric to manage Release scope, not a metric to measure team performance or productivity.

Notice: Illustrations copyright Jurgen Appelo, Management 3.0

Monday, October 10, 2016

Is Time Pressure an Acceptable Reason for Poor Quality?



I worked with many teams who had the same issue. An intense time pressure that led them to react by doing either of or both of the following:
  • Coding in hurry, and falling into too many cycles of testing and bug fixing, which delayed them much more time and made the situation worse.     
  • Delivering a code that is full of bugs, which makes the customer distrust the team.

When I ask developers and team leads, why they fall into this situation? They always point to the same reason. They had unreasonably forced deadlines and pressure. They reported to business people about the situation and they refused to listen. That meant the whole responsibility was on the business people or the customer himself. Developers see themselves as victims of the bad guys. They wish that the world would change around them and give them enough time to do their work the right way.

This perspective gives the whole blame to the pressure of business people and customers and no blame to the development team. And, of course business people blame the development team. This is a finger pointing situation where everyone is blaming others. I would like to ask some questions to highlight my point of view:
  • Who knows more about software engineering principles? Developers, business people or Customers?
  • If a customer pushed you for the sake of optimizing your work, or even as a sort of greed. Is it helpful for you or your customer to ship a buggy code?
  • Do many cycles of testing/fixing support you or your customer to deliver faster or just wasting more time?

Under pressure, if developers decide to voluntarily work all weekends and a lot of overtime and ship the right product, it may be OK, relatively. Developers sacrifice their personal life for the sake of happy customers. It is a lose-win situation, which is not optimal, but at least someone wins.

What is happening is much worse. We fall into a lose-lose situation, where developers are exhausted from working too much overtime, shipping a product with too many bugs and on the other end dissatisfied customers and business people. What could be worse than this?

Developers, please stop trying to change the world around you and start changing yourselves and your responses. You know your craft and you should act responsibly. I would like to give an example of what you should do as a professional.

Your car is broken and you need to fix it. You have a 500-mile journey and you are in a hurry. You went to a car maintenance center. After a careful investigation, the engineer told you that it would take 6 hours to fix. You asked him to finish it in just 1 hour due to your situation. The mechanical engineer knows his craft and work, you assume. I would fictionally describe two responses because of the intense pressure to finish early.
First Response: The engineer just listened to your demands and did an unreliable fix to the car in one hour. You were happy to be on time. You took the car and drove it, and in the middle of your journey at 2:00 AM in an uninhabited place, the car stopped, and the fire caught your engine. What would be your feelings about the mechanical engineer? Are you still happy that he fixed your car in one hour? You asked him to finish in one hour to support your urgency not to make your situation worse.

Second Response: Imagine this. The engineer took your request into consideration and consulted other engineers to optimize the time of fix. And the engineer came back to you with a full explanation, facts, and context to explain the constraints. He told you, ”there is no way to finish in one hour, but we  will do some high priority fixes in parallel and we will skip some minor enhancements. Some other fixes can be delayed until you reach your destination.” With all these optimizations, they could finish in two hours, not less. You were not so happy, but you felt they were disciplined and professional. The fix was well done and you drove your car to your destination safely (but with a one hour delay).

From these responses, which one would be appropriate for the customer? What is the response that is expected from a disciplined engineer or a professional organization? What is the ethical reaction that you should take regardless of the intense time pressure?

Nowadays, software is critical to billions of people's lives. Billions of dollars are lost because of bugs in software systems. People die from bugs in software. Can you imagine a bug’s consequences on radiology treatment machine? A bug in a blood-bank software! A bug in charging a mobile battery that may explode it! Or at least, do you know how many disappointed users there are, because of poor quality software?

ACM (Association of Computing Machinery) developed "ACM Code of Ethics and Professional Conduct" for software developers at [http://www.acm.org/about-acm/acm-code-of-ethics-and-professional-conduct]. The declaration has 8 moral imperatives. The second one is "Avoid harm to others". In our described  scenario, you are not only harming others, you are harming yourself as well.
As a conclusion, please:
  • Do not try to change the world around you.
  • Change yourself and choose your reactions disciplinary.
  • There is no reason to fall into lose-lose situation and harm your customer and yourself.
  • Always write clean code and follow technical excellence practices. 
  • Technical practices will not delay you, but will save you time and hassle.

And remember, Be powerful and be happy.

Notice: Illustrations copyright Jurgen Appelo, Management 3.0

Sunday, September 25, 2016

Google Maps and Agility



I commute driving my car almost daily from 2 to 3 hours, . I live and work in one of the biggest and busiest cities I think, Cairo. If you are not regularly commuting in a busy and a big city, possibly you cannot imagine the hassle and uncertainty of it. It is disappointing. I face unexpected congestion randomly and have a very limited clue on how to manage my trip. Sometimes, I find unexpected congestion, and change my route to another one, assuming it is faster, to find it much worse. Actually I cannot be sure, as I do not have knowledge to be sure. With fear and ignorance, my commute is a misery.

Last year, I started to use a local mobile application named "Bey2ollak". Bey2ollak is an Arabic word means "He is saying to you". Yes, too much English words in only one Arabic word, that written in English characters and Arabic numerals! Bey2ollak is a social mobile application  who breaks famous route into segments and enable commuters to rate the segment from busyness perspective. A rank from "Perfectly Clean" to"Too busy - Avoid" is used. They use nice smiley faces as in the picture. It enables users to easily register account and post comments also. That is all. Recently they added more features but I am talking about my past experience and not evaluating the current state of the tool.




Using Bey2ollak, before going to work or returning back to home, I used to check my route conditions and decide if I should go home now, in which route or if it is better to stay an extra couple of hours at work until the road congestion resolves. Generally better than before, but I still has several pains:
  • The application does not propose different routes. 
  • I have to design my route myself, by selecting all segments manually.
  • Commuters rate segments manually. (Later, they made it automated if you open your GPS)
  • There is no time estimation for the entire route.
  • Sometimes people report on the wrong route segment.
  • Many times reporters got very emotional and start cursing the traffic and the city!

Google Maps app was available at that time, but was not handling traffic conditions of my city.


Recent months, Google Maps added  traffic conditions, and trip time estimation features. Now, I set my destination address, then it displays different routes with time estimates. It highlights parts of the road that has congestion and shows how much time it will delay me. Not only that, as I drive the selected route, it alerts me of better routes that become available. When the situation is changed, it alerts me of a new congestion ahead and tells me how much time it will delay me. 



With all these live information, my commute emotional experience is changed completely. Frustration of uncertainty and limited visibility are eliminated. The road conditions are not enhanced at all, but now, I have visibility and timely information to manage the situation and reduce its adverse impact on me. With Maps, my situation is changed. Even in difficult busy days, which I cannot control, the information given by Maps is calming. I no more got disastrous ambiguous situation hitting me as an unexpected mine. It relieved my emotions that, whatever the route status, I have power of knowledge to decide my route with accurate predictions and choices.


Yesterday, it popped to my mind that, our Agile approach (Typically Scrum) has similar characteristics. It enables me to manage the uncertainty and enables the team and Product Owner to decide what to do. Agile planning and tracking will not prevent problems (like in Maps), but it helps you track them down and helps you to manage the uncertainty inherent in software development. Let me highlight some Agile/Scrum concepts that helps:

  1. Relative size estimates done by the whole team without political pressure from management will help Agile team quantify reliably the amount of features required for the next release.
  2. With Done Definition that treats completeness as 100% criteria. It enforces the team to reliably finish valuable requirements completely to get the score of the finished stories. If not completely done per the Done Definition, they earn zero. It frees them from debating whether some requirements are finished by 60% or 80%. And hence enables more reliable progress visibility.
  3. With every sprint, we measure how much story points are completed. It gives a strong sense of our progress and our velocity regarding the required scope of work. 
  4. If problems happen, and it will, we can re-plan the remainder of the release accordingly.
  5. With Burn Down charts and daily Standup Meetings, the team can spot impediments and delays very early. It enables the team to react very fast to impediments and issues.

So, these Agile concepts/tools does not eliminate uncertainty or complexity of developing software, but it sets the stage to reliably navigate them. It helps in the same sense that Maps helped me to manage the complexity and uncertainty of my commute. Or at least, this is what happened with me.



Wednesday, September 14, 2016

Joined Happy Melly

I just joined @Happy_Melly network! and became a supporting member.

Why is that important?
I love my programming work and find it a joy and it was miserable why current management practices make people unhappy and disappointed unnecessarily. But simply I have no solution. I worked as a manager for 8 years and still can not find how to really manage the right way.

My exploration started by discovering Agile and Extreme Programming and found ways to find joy while developing great application. What was really great, is finding that joy on the team level.

Next, I discovered self organization through Open Space Technology by Harrison Owen great book and mailing list. I learned that, we are already self-organized and happy creatures and poor management just delays us and makes us unproductive and unhappy. But still something is missing in the buzzle.

That missing thing is uncovered recently. I discovered Management 3.0, and found the whole concept of self organization and Agility expanded to all areas of management, even areas that seems untouchable such as performance appraisals and bonuses.

I am learning and exploring all the time, very soon I will share with you my new stories.

Be Powerful Be Happy

Friday, September 09, 2016

Session Review: Next Evolution of Agile Leadership Roles



Session:  Agile Project Manager, Product Owner and ScrumMaster are all broken - The Next Evolution of Agile Leadership Roles
At:     Holiday-inn Hotel ... City Stars, Cairo, Egypt
Date: 8 Sept 2016, 

--------


There was a QA session followed by a session by Ahmed Sidky. My comments here are related to Sidky session.

In my opinion, he was presenting his experience in managing ownership and accountability in his Riot Games company.

First, he showed that, after joining Riot, he found the traditional Agile roles are confusing and makes it difficult to decide which one is really accountable for team results. That situation pushed him to experiment and come up with a different model.

Sidky broke up responsibilities into 35 distinct responsibilities. He was presenting them in the form of plastic cards, something similar to Planning Poker cards but double its size.
At Riot Games, they created 4 leadership roles as following:
  • Team Captain: This is the head of the other three leads. He is accountable about the project. He is the only accountable person in the four leadership roles. Later on, I will explain what is meant by being accountable.
  • Delivery Lead: Responsible about delivery deadlines.
  • Product Lead: Responsible about the product scope, something like Product Owner, I think.
  • Craft Lead: Like Test Lead, Developers Lead and so on. He is responsible about the craft quality and standards of his/her team’s work.
Sidky gave color for each leadership role, for example red color is assigned to the Team Captain. He showed us physical hats with different colors. The only problem is that; the size of hats is a little bit small to be wore by humans.

From the 35 responsibilities, there are 10 that are hard coded to each role and cannot be changed. 

First, the project team conduct a workshop with team members. They list the other 25 role cards and they collaborate to assign each of these responsibilities to these hats/roles.

Then, the team self-organize to assign a team member to each role/hat. There may be some additional conversations and negotiation until the team agree on the result. The result will be that, all 35 responsibilities are distributed on the four roles and a team member is assigned to each role/hat. Each team member can have one or more hats, or none at all of course.
 
Regarding accountability, Sidky described three steps for poor performance evaluation. First Step is to conduct a meeting, understand the problem, and what to do about it now and in the future. There is no blame culture, any one mentioned in conversation is invited immediately.

Second Poor Performance case: Just like the first one. I expect the conversation will be more difficult.

Third poor performance case: Here is where management will take action.

He mentioned that, we cannot overlook that, there are poor members and good members. In some cases, you have to fire poor performing members.

Note: The above description is a representation of my understanding to what Sidky proposed. It may be incomplete or inaccurate. Your feedback is welcomed.

My Personal Notes:
  • I find it is OK to design your role in your organization. Feel free to break the famous Scrum Roles SM/PO if it makes sense. According to Agile Manifesto, roles are not included in Agile Values or Principles. It was described in Scrum and many people find it useful.
  • As Sidky said that, this is RI phase of inventing things. If you are an Agile beginner, be careful and follow some well-known recipes, such as Scrum or Kanban.
  • I find it very self-organizing and matches Agile spirit to let the team collaborate on responsibilities and role assignment.  



It was a fun event, Sidky enjoys a sense of humor. Here are some pictures from the event.








Tuesday, August 23, 2016

"As a system developer I want to ..." User Story

I worked with a team who is used to have stories that represent the development tasks. It was a mobile application with back-end development. I explained to the team that, User Story is simply a story that is related to the system user. The developer is not a system user, he is the developer of the system. User story is the language used between product owner and development team to express valuable functionality. How is a developer technical task for the back-end be of some direct value to the customer or product owner? This representation typically break the core idea of User Story. It clearly break the famous INVEST mnemonic created by Bill Wake. The INVEST contains "V" letter, which stands for "Valuable". Valuable by the perception of end user. The story is a vertical slice of a cake that contains all layers that compose the cake. I really like this metaphor, at least it is tasty.

I was curious to know the team motivation in doing that. I asked several questions to explore the exact meaning of why these not-valuable stories are treated that way. After listening to their answers, I got it. First, it have a size points, which gives them some credit. Second, I found that, the back-end stories are typically a preparation of next sprint stories. So, they actually break down story work into two Sprints. The first Sprint is to develop back-end code, and the second Sprint is focused on developing user interface functionality of those back-end work.

Oh my God. There are a lot of ways creative teams are able to inject the waterfall mindset into Scrum. They easily break principles and values under many weak reasons.

So, let me stress that, this is not a user story, and the way work is divided between sprints is not Scrum. The user story is meant to be totally developed in one sprint, including all required activities. In the experience described here, and in a 3 weeks Sprints, I can expect many integration bugs as well as task switching waste.

In addition to that, the Sprint velocity measure is broken. It sums valuable work of this Sprint with non-valuable back-end work of the previous Sprint. The sense of comparing Sprint velocity to another Sprint velocity or managing the scope of release backlog is broken.

To summarize, the same story has a user interface and a back end work, all should be planned to be done in the same Sprint. Exceptions are OK as they are just exception.

Friday, May 20, 2016

User Story is Not a Documentation Format

User stories intent is not to capture requirements completely. We know that written words are not sufficient to capture requirements for two reasons. First there is a lot of knowledge regarding requirements that are very difficult to document and hence to consume. Second a large part of requirements is not visible. It is like an iceberg, what you see is much less than what is hidden.
The point I trying to say is that, we conduct a workshop with users, developers and testers to discuss, model, elaborate on what should be done. At the end, and as a reminder, they write a brief description about it. Although I like User Story format as an Agilest, but I think the shared understanding concept is much more important than the written words of requirements.
Writing a documentation that is brief is an objective in itself. We rely on short term memory to preserve a lot of knowledge. Some of this knowledge, we may be not aware of its existence.
So, replacing Use Cases or other requirements documentation format with User Story format does not mean you implemented the approach of User Stories approach. You have to think of it per the original intent of the approach. One of the models that is helping us understand is the 3C model of Ron Jeffries.This model describes User story as Card, Conversion, and Confirmation.
By Card, it means a simple and small index card is sufficient to denote the User Story. One of the negative features of most requirements management software tools is that you can write any amount of content per User Story. By ensuring the limits of physical card constraints, we make sure of the small amount of contents that will be written. Reaching the physical limits is a good indication of either you are writing a lot of un-necessary details or the story is so big and worth breaking it into two stories.
The second word is Conversation: User story is not written by some person and handed off to the team for implementation. It it actually emerge from conversation between users, developers and testers. It represent a shared understanding rather than a complete and contractual specifications.
The third word is Confirmation: It the assurance of that, all conditions, and scenarios expected from users and testers are covered. It ensure we are not only thinking of happy scenarios, but also all scenarios and special cases.
There is no typical importance order for the 3Cs. Rather, they are complimentary to assure User Story is not a requirements documentation format, but a methodology of working with user needs that is aligned with Agile mindset.
User Story usually written in the format like this: 
As a , I want to  so that

Usually, the format may attract people of comprehensive documentation mindset to compare it with other formats. But the format is actually the least important part of User Story. 

Sunday, March 27, 2016

Agile Business Value

Many times, you need to prove to your customer and business people the value of adopting Agile mindset, methods and practices. The following resource are very valuable in this regard:

1) The Business Value of Agile Software Methods by David Rico; Saya Sone; Hasan Sayani Published by J. Ross Publishing, 2009
This book has useful info on business value and return on investment of Agile methods and practices.

2) There is a report named "2015 State of Agile Development" from CEB (Corporate Executive Board) Applications Leadership Council. 

Monday, March 14, 2016

Discipled Agile (DAD) 2.0 and Agile

Disciplined Agile just has the same values and principles of Agile, with expanded terminology and additional 3 principles. It replaced working software with working solution, customer with stakeholder as example. This changes in my understanding of Agile Manifesto are inclusive of everything Agile. So, confidently, I can assure Discipled Agile (DAD) 2.0 is one of the Agile methodologies.

From another perspective, Disciplined Agile congested Agile, Lean, Modeling and many other practices into one huge choice based processes framework. It has 4 options of life cycles, that covers iteration oriented, flow oriented and even lean startup based one. I can be provocative and say, Discipled Agile is more Agile than Scrum.

See more details at:
http://www.disciplinedagiledelivery.com/lifecycle/

Tuesday, February 16, 2016

Disciplined Agile Delivery and Agility

NOTE: The below article is written on DAD, not DAD 2.0. My opinion on DAD 2.0 is different.

Here is my opinion about Disciplined Agile Delivery in relation to Agility.

Disciplined Agile Delivery (DAD) is a software development methodology that targets the enterprise and promises a disciplined and scalable methodology. DAD is formulated and published in the book: Disciplined Agile Delivery by Scott Ambler and Mark Lines.

To be clear, my reference understanding of Agile is through the Agile Manifesto values and principles. The Manifesto is the most agreed on and reputable framework that formulates what is  Agility. The manifesto is defined and signed at www.agilemanifesto.org

DAD has 3 phases, Inception phase, construction phase and Transition phase. The inception phase is where all initial preparations are done. The construction phase consists of multiple short iterations, each is time boxed and produces a potentially consumable product. The last phase is the Transition phase where all the deployment happens. 

In my opinion, the flow is a form of waterfall. The transitioning phase is the holder of all trouble. The team will tend to build increments very fast in Construction phase and then slow down a lot in the Transition phase, where all issues and bugs surfaces.

The separate transitioning phase is what makes DAD not an Agile methodology. It dose not produce valuable and deployed software with each construction iteration, but only at the end of the project, in the Transition phase.

I want to remind you that, putting agile in the name of a methodology does not make it an Agile methodology necessarily. Although DAD uses a lot of techniques from Scrum, XP, Kanban, and Lean, the introduction of Transition phase breaks one of the main principles in Agile.

Scott Ambler, the main author, has many critiques of Agile, and his methodology is meant to recover the lack of discipline that exist in Agile mindset and methodologies, per his thinking. Even though, he borrowed a lot of techniques and ideas from Agile methodologies. 

If we look through history, we find that, Rational Unified Process (RUP) which was developed by Rational Software (and later acquired by IBM), consists of 4 phases. These phases are Inception, Elaboration, Construction and Transition. RUP is an iterative and incremental methodology as defined by its authors, however, it is practiced as a heavy weight documentation-oriented and waterfall methodology. 

After disastrous implementation of RUP in may organizations, Scott Ambler developed Agile Unified Process (AUP). AUP is a major simplification to RUP. AUP distinguishes between two types of iterations. A development iteration that results in a deployment to the quality-assurance and/or demo area, and a production iteration that results in a deployment to the production area. This is a significant refinement to RUP but still have the risk to carry a lot of waterfall like practices. In the core of Agile, every iteration should result of potentially shippable software. This deficiency in AUP appears as a heritage from RUP that could not be overcame.

Later on, Scott Ambler and Mark Lines authored the Disciplined Agile Delivery book. Although he got rid of the RUP Elaboration phase, he did keep the Transition phase. That makes his new methodology in practice, applied as a kind of waterfall especially if implemented by a team who that is used to RUP or AUP.

My conclusion is that, DAD by design is a kind of waterfall despite its heavy borrow of Agile practices. This is mainly because of the effect of the Transition phase. If you get rid of that phase, and made the transitioning activities as part of each construction iteration, it could work. However, a high risk is introduced if the methodology is being applied by a team who are used to work with RUP or AUP. They will tend to use the old practices and will not harvest innate prosperity of Agile mindset.