5 actionable you can take today to be more agile
 

Be More Agile

Most of the teams in the software world follow Agile process and practices. Following Agile is fundamentally different from being Agile and in this article, we will talk about some of the actions you can take today to be more agile.

do you follow?

  1. Shed Ego:  Ego is a big blocker for our progress irrespective of being in the Agile world or not. But this becomes even more evident and blocks our every step in an Agile environment. There are lots of articles about egoless development.
  2. Be open to collaborate : When we are open and talk our mind, we automatically become more agile. The restrictions and mental blocks to speak our mind openly to the team are the biggest bottlenecks to free flow of information and ideas. Psychologists call it emotional security to speak our mind.
  3. Don’t Use communication tools: In this age of technology, the tools are plenty for communication,  but none of them provide the connect of the face to face communication. (Agile principle)
  4. Focus on the outcome: Lot many times, the agile manifesto is being misinterpreted (“working code is a measure of progress”).  Unfortunately, it does not talk about production. Some teams get very complacent when they get their working code in “QA” or “Stage” environments for example. There is no result when the working code is not in production. At the end of the day outcome matters.
  5. Get things done: Just like any other methodologies, the trap always exists when teams get lost in the process and meetings. The important part of the business and the product is to deliver things. So never move eyes away from the delivery.

These are the few actionable you can take today to be more agile and be awesome developers and technologists. So take action now!

What are common Agile Methods?
 

Agile Methods

The Agile is not just following Scrum or XP. There are many other agile frameworks or methodologies available in the Agile world which are leveraged based on type of work or a project. There is none better than other.  The use completely depends on the type of the project you have.  There are many methodologies available in the market while I will be listing down high-level details about some of the core methodologies below.

  • Scrum
    • The team works in iterations (Called sprints) that are typically 2 or 4 weeks.
    • The engineering practices are not prescribed.
    • The scrum does not encourage change within sprint once a commitment is made.
    • The backlog is prioritized while within sprints team decides how to go about picking items. The priority is typically given by product owner.
    • The releases happened after the end of iterations.
    • The scrum can be used for non-software products.
    • Encourages feedback early while it’s fine to reach to the point till you have sprint review.
  • Extreme Programming (XP)
    • The team works in iterations that are typically 1 or 2 weeks.
    • The engineering practices (TDD, BDD, pair programming, automated testing, refactoring etc.) are prescribed.
    • The XP teams are open for changes as long as the feature hasn’t started or they have similar size of an item which can be swapped.
    • The work is done in strictly priority order. The priority is determined by the customer.
    • The focus is more on small and frequent releases.
    • XP focuses on programming.
    • Immediate Feedback loops.
  • Lean and Kanban
    • The lean concept has come from lean manufacturing where the focus was a continuous flow of work and eliminating waste (Muda).
    • Kanban (Billboard or signal board or visual board in Japanese) is one of the lean methodology sometimes referred as Lean Kanban.
    • The core focus is on visualization, work in progress limits, flow, and continuous delivery. The work is in one of the categories (to-do, doing or done). There could be N-number of categories.
    • When we talk about software, it is most suitable for support kind of work.
    • No required time-boxes or iterations.
    • No set process roles are prescribed unlike Scrum where you have three roles defined (Scrum master, product owner, and team member)
  • Feature Driven Development (FDD)
    • An iterative and incremental software development process which is often referred as a lightweight Agile process.
    • The focus is on features.
    • The main purpose of FDD is to deliver tangible, working software repeatedly in a timely fashion.
    • The unit testing, pair programming, refactoring is not important.  Modeling language (like UML) is leveraged and documentation is not mandatory at all.
  • Agile Unified Process (AUP)
    • Simplified version of RUP (Rational Unified Process)
    • The four phases are inception, elaboration, construction and transition.
      • Inception – Stack holder acceptance, Initial requirements, high-level architecture, and scope is baselined here.
      • Elaboration – The detailed design and architecture are accomplished in this phase.
      • Construction – Working software building incrementally.
      • Transition – Release and deployment
    • The focus is on TDD, Refactoring, change management etc.
  • Dynamic Systems Development Method (DSDM)
    • Focus on developing the system dynamically based originally on Rapid Application Development.
    • Incremental prototyping
    • It has primarily 5 phases
      • Feasibility Study
      • Business Study
      • Functional/Business Model Iteration
      • Design and Build Iteration
      • Implementation

Above is very high-level information to get a hang of it. I shall be writing individual blogs about these methodologies in detail in my upcoming blogs.

How can I grow vertically in product based organization?
 

As an Agile team member how can I be an expert at project is one among a common question I hear every time. The world is changing so fast, the evolution of tools and technologies making life so easy when it comes to implementation or writing code. When you talk about career, everyone wants to grow vertically and the easiest option I see to achieve this in product based companies is to get better at product and domain in addition to fulfilling your agile roles and responsibilities. This would help you to stand out in the crowd. To be honest, this is an easy path which lot of others do not want to take.

Vertical Growth

I am listing here top 10 ideas to be considered to grow vertically in product based organization.

  1. Spend 30 minutes to an hour every day to learn about the product by playing with product, testing out functionalities, reviewing code other than your normal work.
  2. Review existing documents around product. Whenever you see an opportunity correct them. Document your learning and contribute your knowledge in organization PAL (Process Asset Library). Writing or teaching anything to people helps you to move the knowledge to your permanent memory.
  3. Whenever you work on any sprint item (like bug, story, tech debt or spike), ensure you understand the user value proposition of that. Always ask yourself why I am doing what I am doing. How does it helps business?
  4. Understand all the integration with your product.
  5. Search on internet to find competitors. Find out what features we are lacking what our competitors have. What is that we have and others don’t have? Propose PO your learning and ideas.
  6. Participate in calls related to vision, roadmap or release planning.
  7. Communicate more with business owners. Understand priorities, business need and what is coming next.
  8. Ask question when in doubt. No question is a stupid question.
  9. Participate in showcases/demos and cross functional calls. Ask questions. Share your knowledge to others in team.
  10. Once in a week have a session with whole team to talk about product, domain, innovations and learning. Encourage everyone to share their thoughts.

I am sure doing some of above would boost your career in product based organization.

How can an Agile Leader be successful?
 

I am listing most important factors which an agile leader must focus on, in order to be successful in his/her role

  • People, people and people

  • Building Relationships with all the stakeholders

  • Business Alignment (Clarity of vision and mission)

  • Self-Organizing Teams

  • Sprint Success and Continuous Improvements

  • Everyone contributes 

  • Relationship within team

  • Collaboration

  • Promote “Fail Faster, succeed sooner”

  • Frequent releases

  • Remove impediments

  • Frequent feedback loops

  • Lots of fun

  • Process alignment

  • Visibility on current status

People

Let me tell you honestly, there is nothing more important than people.  As a leader, you should focus on people, their careers, growth, motivation and anything what you can support them to add value to their personal lives. Don’t forget to appreciate good work and at the same time it is important to provide feedback around areas of improvement.  When you think of growth, think about your team’s growth. When they grow, you grow.

Provide them opportunity to become better individuals. Inspire them to learn and get better. Feel pride in their success.

Building Relationships

Strong relationship with team and stakeholders make life easy. It’s not just about bringing in empowerment while at the same time it is important to understanding everyone’s need and expectations.  The great relationship with business, management and team helps you to have

  • Better insight
  • Access to more information
  • Align people
  • Open culture

Business Alignment and Vision

If you don’t know where you want to go, you will reach nowhere. As an agile leader, you must ensure that there is a clarity of vision and mission for you and your team. Moreover everyone is aligned to business needs and expectations. You should often ask yourself and your team about USP (unique selling proposition) of what you are building.

Self-Organizing Teams and autonomy

Don’t hold your team too tight that they can’t breathe at the same time don’t leave them to do everything by their own assuming they would become so called “self-organizing teams”  by themselves. The ultimate goal should be to build self-organizing team and if you are successful in doing so, the chances of you being successful is very high along with your team.

Sprint Success

Always focus on sprint success. When you start, do it less and then improve. Never get into discussion with business or management that we are delivering enough for our need hence meeting commitment is not important.  Do whatever it takes to make sure your sprint is successful.

Everyone contributes and Continuous Improvements

If this doesn’t happen then slowly you would see your self-organizing team start deteriorating.  Everyone has different skill and competence hence you can have different expectations while everyone has to contribute. One rotten apple spoils entire basket and this no different here.

Relationship within team

If you have happy team that gel well with each other, you are likely to do much more. If you’ve highly competent individuals in team but team members don’t go well with each other over a team which has lessor experience and competence with strong bonding then your chances of getting better output in team with good bonding. Do whatever it takes to make your team align and build a bonding among them. By doing so, you are significantly improving the chances of your success.

Collaboration and Communication

Agile team cannot run in Silo. The collaboration nothing but working with cross functional teams to accomplish a task. This encourages communication among business owners.  The communication within team is also very important. The output will be produced by team and not individuals.  It helps in removing impediments faster as well.

Promote “Fail Faster, succeed sooner”

It’s not a perfect world. In order to be successful with Agile there should be an environment where everyone encourages individuals to experiment. It’s OK to fail and that’s what lead us to be successful.  Fail faster, succeed sooner is something you should not just feel while you are expected to enforce that in your team.

Frequent releases

Release as much as you can. I have seen teams releasing every day or even post every feature completion. This is a challenge at a times or product which are quite big and needs significant testing. More you do, simple it becomes.  The moment you start thinking about releasing frequently, you would focus on automation tests.  That something most times become last priority which is not at all good.

Constant feedback

Don’t wait for showcase to provide feedback. The code review phase is not important to provide the challenges or best practice. Talk more. Provide feedback then and there. Look for ways to get the feedback from customer, PO or other stakeholders as soon as possible.

Lots of fun

Start with fun and then get on to work. Don’t wait for you to be successful to have reward. There is going to be celebration for that as well while create an environment where everyone feels comfortable and enjoy working.

Process alignment

Arrange a training. Talk about process. Doing agile is probably easiest thing while doing it RIGHT is what really needed right mindset. There are many teams I have seen they do “waterfall agile”. They are basically trying to do waterfall within each sprint.  Not good!

Visibility on current status

Create various matrix to ensure things are on track. Utilize standard artifacts like burndown charts, velocity report etc to see where you stand. You can fix the issue and come up with finding a right solution only when you know how are you doing.

Agile Abuse – Scenario 7 – We are agile hence lets update the story during run time
 

Neha – Developer 1, Bob – Product Owner, Peter – Agile Coach

Neha – We are always missing acceptance criteria and functional details in a story. It is really tough to commit a story with little or no clarity.

Bob – The Agile lets you evolve the requirements as you move. This is perfectly alright.  I am within the boundary. I will write the acceptance criteria when I get the time.

Peter- The requirements can evolve and that’s an advantage for a customer while stories cannot keep evolving during the sprint.  You have an opportunity to refine the acceptance criteria. If the functional requirements are not clear or acceptance criteria cannot be determined during planning/grooming, the story shouldn’t be committed. It should be moved for a later sprint.

Bob – Can I write the acceptance criteria and later change it altogether during the sprint as we progress?

Peter – No for sure. The change in a story once committed is a “scope creep”. You must move that to the next sprint of post-re-estimation, you might have to remove some other stories out of a sprint. Ideally, you are not allowed to change anything during a sprint. Adding more details to acceptance criteria to make it more clear as you move should be fine, though.

Bob – Fair! I will take out the stories where I don’t have clarity.

Challenge – Writing a one-liner description for a story should be fine and we will keep updating it while working in progress during the sprint. 

Scenario 1 – I leave very early because I finish my work and I pick very less because this is all I can do

Agile Abuse – Scenario 6 – Story point is not about time, not even a range
 

Sumant – Developer 1, Veena – Scrum Master

Veena – Sumant, we are almost at last day of sprint and your 3 pointers are not yet done. Do you see a risk? What is the tentative time you think you would take?

Sumant – I can’t tell you. Agile says that you cannot convert story points to time hence 3 pointers can take 3 days or 3 months. All valid in agile.

Veena – Why do you estimate your stories?

Sumant  – So that we know whether we can do that in our sprint or not.

Veena – And a sprint duration can be 3 months too?

Sumant – Oops, I got it.  My bad!

Challenge – The story point is not about time, not even a range.

 

Scenario 7 – We will unearth the acceptance criteria and requirements for a given story as we continue with development. Writing a one-liner description for a story should be fine and we will keep looking at it while working in progress during the sprint.

Agile Abuse – Scenario 5 – Let’s play with estimation whenever we want
 

Ron – Developer 1, Amy – Scrum Master

Amy – How come we committed 45 story points and we accomplished 51 though I have not added any extra work to sprint.

Ron – The performance improvement story was a little complicated hence I have added 6 additional points to it.

Amy – Once an estimate is done, it is not supposed to change in any case. If so, the whole point of estimation has no value.

Ron – Sorry, I will change that back to original and add the challenges encountered with that story to our process asset library.

Challenge – It is perfectly alright to play with estimation at any point in time.  

Scenario 6 – Story point is not about time, not even a range

Agile Abuse – Scenario 4 – Sprinting means running super fast
 

Paula – Customer, Amy – Manager

Paula – Amy, you mentioned that Agile is supposed to be faster. Why don’t you speed up the work with the same team? Sprint velocity is supposed to improve sprint after sprint and the speed of work should constantly increase.

Amy – Too much speed can affect the quality of work. Agile promotes sustainable development. In a long run, the overall benefit with respect to quality is going to be more compare to quantity in most circumstances while the sprint can run with a pace and all you can expect is better quality sprint after sprint.  100% utilization is an economic disaster.

Paula – OK. Got it.

Challenge – ‘Sprinting’ means running super-fast.

Scenario 5 – It is perfectly alright to play with estimation at any point in time.