Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

July | Article Round Up

What you read, is what your interests are and I can clearly see from my reading list. 

I have tried to categorise them better this time around, so let me know if this is something that you guys are enjoying as well. 

Career:
  1. All about Goal Setting
  2. 10 Steps to Achieve any Goal
  3. 4 Tips to achieve your goals (Ted talks)
  4. Your career best effort ( again from one of my newly found blogger James Clear)


 Books:
  1. Brene Brown's Digital Library
  2. Books to read if you are suffering from Imposter Syndrome

Overcoming Challenges:

  1. To know that you can actually do what you put your mind to, the writer tells it all how he photographed the Royal wedding.

Agile:
  1. Spotify's health check model
  2. Levels of Agile Maturity 
  3. Success by being Agile

Working Moms:
  1. Kids of working moms turn into happy adults
  2. 6 Women share their return to work stories after maternity leave

Others:
I couldn't really find a category for it and I am generally interested in a lot of stuff when I read, here are some of the selected reads I thought might be interesting to this blogs audience.
  1. Why you can focus more in coffee shops than open plan offices
  2.  What the experiment of employees working 4 days a week found out
  3. open plan offices reduce face to face communications
  4. why liberal arts and humanities is as important as engineering
  5. New York Stock Exchange gets it first women chief 
  6. Only 25% of workforce is female in India 
  7. Lauren Powell and her story of inventing her brand
  8. 6 Pillars of Creativity
  9. When a stress expert and author battles mental illness 
  10. Surprising facts of why Women CEO's don't expect much support at home or work.
My favourite tweet for this month:





If you enjoyed this, you might want to look at the Article Round up for June.

Increase your Productivity- 3 Ways

We all have 24 hours in a day.

Some can work and use it like there's no tomorrow and some will procrastinate and be lazy and not get anything done. Which one is you?

The goal is to figure out how to maximise productivity. So, if you are someone who can't focus for 10 minutes straight without scrolling through your twitter or Instagram feed, here is some help for you.

Finding your Zone- athlete’s are known for getting into the zone, some visualise winning, some will pin their goals and re-affirm everyday and some will close their eyes and feel themselves winning. 

The “state of free flow” happens when you can replicate an emotion or the readiness by simply listening to the same music or reading your affirmations. One you are present in the zone you can do what you are best at without feeling the urge to browse or being distracted. Read more here about the state of free flow. 

The state of flow, will actually feel something like this for you:
  1. You are completely involved in what you’re doing
  2. There’s clarity:-you know what you have to do
  3. You know that the activity is doable, that you have the necessary skills to complete the task successfully.
  4. You lose your sense of self and all of your worries and concerns drift away.
  5. You lose track of time and you’re completely focused on the present moment.
  6. There’s an intrinsic motivation—whatever produces flow becomes it’s own reward. (Source)
Remove Stress- when you do what you love, you feel stress melting away. 

Work stress has been categorised into multiple stages:
1. Honeymoon stage
2. Full throttle stage
3. Chronic symptom stage
4. Hitting the wall stage
5. The opposite

Removing stress is a simple way to increase your productivity, no one tells you watch back back to episodes in Netflix, you can sustain it because you like watching it and to doesn’t stress you out. Only if you could replicate that feeling while working, you could easily work for hours. 

So, why are you stressed? Is it because you still have to found the right job or area of interest you would like to work in. 

Try these below points to try reducing the stress:

  • Take Breaks- take whenever you need it, to focus on yourself, for self care or just to find your sanity. Psychology Today talks about how “When we work, our prefrontal cortex makes every effort to help us execute our goals. But for a challenging task that requires our sustained attention, research shows briefly taking our minds off the goal can renew and strengthen motivation later on.” Read more here 
  • Exercise- changes your thinking skills  and comes with numerous benefits. Personally, I think my best when I go for walks and have seen the benefits first hand. I even walk when I feel stuck in situations. 
  • Plan your way to the ideal job- You should move if you don't like the mess you are in, you are not a tree. So, instead of being in a toxic environment, it's better to look for the next job. There are lots of platforms and ways to look for new jobs or find mentors who can help you. 
10,000 Hour Rule- efficiency is about how you have mastered the domain. This means hours of practice can not only make you efficient, it will also ensure you inspect and adapt your techniques or domains. 

To bring in more structure, the following strategy/tools usually bring in results:
  1. Pomodoro technique- this is one of my favorite tools right now, specially when I am trying to focus amidst a million more things to do. When I try to finish a task whether its the research behind the article or writing a post I mostly always wander. Using the timer, I know that I have a set time during which I have to finish the task I have assigned  and in most cases I have been able to get it done. So, if you have problem focussing, give this simple timer a go. 
  2. Breaking hours- a lot of people swear by their calendar and keep it every organised. The goal I think is very similar, when you break down the hours you are just increasing your focus because you time is limited and your work pin pointed. For me this simply translates to getting it done.
  3. Dividing your work - you eat one spoonful at a time, taking a project doesn't mean you have to get it done in a day. So, stop stressing. divine your work, break it down to simpler tasks, where you can't slice to down anymore. Then you prioritise it and thats how you start. consider the total number of tasks, time it will take you to get it done and how much the you have.  don't tress abut tomorrow, just switch on the tomato timer and work on the first task for now.


What do you think? Have some secrets you want to share that works for you, leave them in the comments or share over twitter

(Pic courtesy: Free stock Photography and google images)

Agile| Technical Conference| India-Bangalore

Jun 11, 2018 | | 0 comments |

Image result for conference

If you are a learning and likes attending conferences, here's one coming up in Bangalore (India). to know more about the organizing committee, click here.
Here’s what the Technical Agility Conference is all about: 

In today’s environment, everyone is seeking for the luxury of stability but very few of the organizations succeed to achieve it. 

Today’s market is completely volatile and unpredictable where you never know what’s gonna happen next and the common question across all the mind is “How do I do this?” The Technical Agility Conference gives a platform to meet, share & discuss with the experts around the globe under one roof where you’ll learn the meaning of Technical Agility, what it means to your organization, and what does it take to lead your organization towards true 

Technical Agility, which is fundamental to achieving true Business Agility. The Three Pillars of the conference: Culture & Collaboration - Enterprise Agility Product Stability & Reliability - Built-in Quality Fast Delivery - Time to Market Conference details: 

Conference Date : August 10-11, 2018 
Website: http://tac2018.com/ 

(Pic Courtesy: google images)

Why is creativity important in agile?

Majority of teams and organizations believe, agile is about ceremonies and productivity and leveraging the flexibility by forcefully changing requirements and showcasing books and authors on how it has been done.

 In ‘Building the Agile Business’, author and digital strategist Neil Perkin describes an agile business as being ‘velocity x focus x flexibility’. In other words, a business that is focusing its efforts on moving in a clear direction, but that also has an in-built ability to adapt and change course if and when necessary…..Taking an agile approach enables brands to test new ideas early on and to adapt easily to changes to ensure maximum success. 

In most scenarios this over used buzzword has also created myths around it that very few can differentiate with reality. Like doing stands up doesn’t make you an agile team. An organization isn’t Agile if only teams are forced to change without telling them why the change is happening. It only leads to bitterness.

There are the supporters and the naysayers who argue over whose agile (implementation) is better. They quote authors and books and bring out snippets of blogposts and argue their case. In all this chaos, I have barely seen teams question what they do and why they do? Why the change?
Creativity often ignored isn’t considered as mainstream thought process in resolving real time problems. The flexibility or adaptability in Agile is sometimes taken as a license to leverage it without thinking.

While certain outlines needs to be adhered, creativity or free thinking can always help resolve problems even when it revolves around process. The most creative individuals are those who can see the things that everyone else misses. 

Looking at data trends in an agile team can tell you where lies the core problem, to put an end to mechanical retrospectives and really finding ways to get the team talking needs creativity and to eventually see what’s working and what’s not and to better the team is about thinking differently.


So, should we incorporate in Agile training's about the need of looking at a set of problems  and thinking how to resolve by adhering to your team culture, by encouraging team members to come up with a new set of solution, bring the team together in discussing collaboratively and telling that it’s not about the tools, it’s about you. Bring you to the table, bring your ideas, disagree when required and respect the difference of thoughts. 

(Pic courtesy: Google Images)

Interactions within Agile Teams- The SCARF Model


Image result for SCARF model

“In a world of increasing interconnectedness and rapid change, there is a growing need to improve the way people work together. Understanding the true drivers of human social behavior is becoming ever more urgent in this environment.”- David Rock

We talk about creating self-organizing team and encouraging team dynamics in Agile but what we forget to mention is how it should be done. This is where SCARF model comes in- Social neuroscience explores the biological foundations of the way humans relate to each other and to themselves. From this a theme emerges from social neuroscience- Firstly, that much of our motivation driving social behavior is governed by an overarching organizing principle of minimizing threat and maximizing reward.

Which simply put means we have to ensure our Lizard brain (the part which tells you not to change, take a risk and ensure you continue to live by keeping you safe from trying out unknown things) doesn’t feel threatened at any point.


Image result for agile teams

The SCARF model involves five domains of human social experience: Status, Certainty, Autonomy, relatedness and Fairness. These 5 domains will either trigger the rewards or the threat thought process.  This also means even during conversations you want to “rewards” trigger to go. This will ensure positive discussion and participation plus engagement.

Certainty and Autonomy out of the five is directly related to you. For example- do you feel empowered that you can make your decision in the current job title? The empowerment  cannot be influenced by anyone else.

The other three Status, Relatedness and Fairness are all influenced by “others”…. Like do you feel you are treated fairly?

So, this is a mix bag of social influence which allows you to feel empowered and positive or otherwise. The dynamics can be created, so if you are a team member or scrum master or manage a team- you need to ensure that these 5 fundamental cornerstones are all in the positive side of things. If by using all of these, we can ensure that a sense of fulfillment, balance and progress within team members can be created- the self-organization will start forming very soon.

Here are 3 ways to build on the improve the team collaboration:·
  • Explain the change (why) - don’t enforce without talking about the big picture.
  • Show why it matters to them(how)- how it can impact them and what usually happens
  • What is expected from a specific role (what)- being articulate about the responsibility of a scrum team/member

If we are successful in ensuring all of these are considered, the team  dynamics and communication will be positive. 

(Pic courtesy: Google images)

Scrum Master: 5 Kinds

Whether you are in an organization that follows Agile or not chances are you already have pre-determined notions about Scrum Masters- their roles and responsibilities.

In my experience of working within the Agile domain in India, there are five kinds of Scrum Masters I have come across:

  • Managers- This specially happens when the organization is moving into Agile initially. Reasons are often genuine and till a scrum master is identified in a team, the team manager in some cases will volunteer for the role. Also, managers who like to know what exactly is happening in the team so they step up into this role which always might not be a very good sign.
      • Pros- Understanding the role will eventually help the manager better appreciate the role. Boosts positive communication within the team and change in process.
      • Cons- it shouldn’t be the case where micro management is the agenda and so why not take up the role and still be the decision maker instead of allowing the team to self-organize
  • Tech Leads- Some organization focus on having adequate experience required for the role of the Scrum Master, the focus is on people who have considerable domain knowledge and its mostly been in the industry ten years or more.  
      • Pros-The vast experience of a lead could help the team manage the domain and deliver work with better quality. 
      • Cons-It shouldn’t end up being a practice that others don’t speak up because the lead is always right. 
  • Project Manager- The team project manager takes up the role as natural transition in a lot of cases. While the project will definitely be delivered with this one in charge, being a servant leader might not be something that will be easy to adopt to; where team calls the shots.
      • Pros- Communication, delivery and milestones will always be in check.
      • Cons- unless the right mindset has been achieved, you don’t want to encourage/continue with the command and control situation.
  • Functional Team Members- This happens commonly as a core team member is either assigned or volunteers to take on the role. This means a split of hours for being a Scrum Master and performing the core competency work.
      • Pros- Buy in within team is easier
      • Cons- Time management during deadlines; the time split doesn’t mean when extra hours are required you drop the scrum master responsibility and take in more hours to finish for example testing.
  • Full Time Scrum Master- Very few organizations will go ahead and hire full time members into this role. When it does happen one Scrum Master is assigned to at least two teams and the unit is very confident of the them working within Agile methodologies. 
      • Pros- Someone available and accountable to ensure the process is in places and problems are looked into and resolved immediately.
      • Cons- Dedicated scrum masters don’t mean they are administrators for the team, filling out details (like in the agile tool) that should be done by everyone themselves. Also, lack of discussion on what the role is about and the responsibilities are by management can create misunderstanding within team members. 

What have you experienced or observed?

(Pic courtesy: Google images)

Being Human in Agile

Agile is one of the most-discussed subjects in any process domain.

With commercialization and certification now so easily available to many, the approach has become easier to learn and implement, and with that has come the liability of seeing it as only a set of rules and practices. The "individual" who was the center of the process has now taken a back seat among the fancy tools and apps. Among many, Agile has become only a term.

As an Agile coach working with multiple teams and organizations, I have always felt that miracles are expected just because you gather together for 15 minutes. We look for data and stats and obsessively check tools. We have made the tool bigger than the process. Rarely does anyone talk about the human factor in Agile. No one wants to take the time to make the connections; we only want the productivity increased.

Have you ever noticed how you work your best? Let’s take a blind guess — maybe you like the freedom in the way you work, the human connection with your peers, and an understanding manager or mentor. No matter which process you are part of, doing your best work shouldn’t change.

If you are still old school like me and prefer the human connection, here are three ways to bring it back.

Storytelling

Don’t approach an Agile transformation with hard-set rules and terminologies. Instead, take the time to explain why, as a team or organization, you are going for it, what benefits you are hoping for, and the challenges that will be encountered. Tell the story of failures, recall the successes you have seen, how you have mentored or coached other teams, and the fact that every transformation is unique and should be treated as such.

Hear their stories, too; try to create a story card. Divide a paper in four quadrants and create your guided storytelling pattern. I have seen that when given a structure to tell a story — based on a question or an activity — people respond better, and it opens up a real conversation rather than just encouraging free-flowing conversation.

You can choose any of the following to create your story card for the teams and then talk one-on-one to understand them:

  • Myers-Briggs Type Indicator score (personality type): Try the free online assessment. This is just for fun and provides some insight into the person. Even if people disagree with the results, they will talk about why it doesn’t match up.
  • Moving Motivators: I find it interesting to see the most- and least-favorite motivators; it's usually an eye-opener. Asking the right question along with this assessment helps form some perspective you will need as a coach or manager to work with each individual. You can find the game at the Management 3.0 website.
  • Who you are: That 30-second elevator speech is rather difficult when you take out of the equation their job title or technical domain expertise. People really must think about who they are, and that’s what you want.
  • The improvement you would like to see in your team/process: Depending on their comfort level, people will talk. Trust me on this; you will get more information here than from looking at the trends in your team's velocity.


Mind Mapping
Sometimes we think better when articulating clearly, and the train of thought is easier to chase when we can come back to it. Mind mapping is a wonderful tool that can be used in various scenarios to get to know a person and to explain the process, and it can even be used in retrospectives. The transformation doesn’t need to be done in the same way everywhere. Learn about others and who you are working with, and bring new techniques to work that bring out the personal point of view and perspective.

Visualization
Reactions will always change more when people see something than when they are told something over and over again. Instead of telling teams that they are full of flaws and that productivity and velocity have to increase, try value stream mapping with the team. Let the team draw with colored pens and crayons and have some fun. Then let them see where they have been lagging. When realizations come from within, changes are easier.

The bottom line from all of the above is that we are trying to keep the uniqueness of an individual and not trying to assume that everyone is the same. Data matters; however, you won’t know the authenticity of the data if the team is always gaming it up to protect themselves from you.

Yes, we are busy — always busy moving from one meeting to another. But not even for a second do we think that the human connection is replaceable with a process or data. When we showcase the human within us and try to understand the other person, it makes the transformation and the assumed role much more fulfilling for all.

This article was originally published in Scrum Alliance

(Pic courtesy: Google Images)

Tools- aren’t the answer to your Agile Transformation

The most hyped up idea during an Agile Transformation is the search for tool that would best suit your organizational needs. Tools is necessary, however isn’t the priority in your Agile journey.

In the process the focus shifts to the tool and then purpose of the transformation is lost. It reaches a point where transformation is equated with tool.


You don’t need fancy tools and a huge budget to start something small. Start your journey with a whiteboard, something that the team has to work on and can play around with it, changing and adding metrics or creating their own customized dashboard.

You can even try a team cork board, or use simple sticky notes or free software to try out the teams comfort level. Tool should be part of the process, not the process.

There are lots of reasons, why you fail in agile and tool shouldn’t be one of them. 
So, find ways to ensure you are Agile in reality. 

To know more about Agile tools, try the links here and here.

(Pic courtesy: Pinterest)




The Project Managers Guide to Mastering Agile- Book Review

The book was sent for review, though I chose it amongst others. The book piqued my interest because project management and agile are considered contradictory ideas.

Published by Wiley, the book covers all aspects of agile and how its different from the traditional waterfall.
What it covers is:
  • Provide a better understanding of what Agile is
  • Talk about the roles and how they are different in Agile
  • Take the main discussion points from PMBOK and explain how the same topic is looked in Agile
  • Dedicates a chapter to Agile tool- about Version One specifically.

·         The book is categorized into 4 main section:
§  Fundamentals of Agile
§  Agile Project Management
§  Making Agile Work for a Business
§  Enterprise Level Agile Frameworks
·         Chapter 11 onwards, the discussion focuses more on understanding Agile at deeper level and subsequently talk about Scaling Agile, the concept of Agile Transformation and towards the end  Frameworks
§  SAFe
§  DAD
§  Managed Agile Development Framework
·         The case studies brings in the how changes happen in reality, the challenges and how to overcome them.

·         The added benefit is the glossary of terms, so someone very new to the concept of Agile doesn’t need to go through another book or web, but can simply get all the terminologies from right here.

Total No of pages
399 (including index)

Who should read this Book?

  •        Project Managers moving into Agile- This book is caters to both experienced and new project managers. Apart from explaining the concepts, the book talks in details about all aspects of traditional project management and its changing roles- from estimation to time management.
  •          Sponsors for Agile Transformation- The case studies are a great way to look into the challenges along with the scaling frameworks. While Agile tool has been discussed here, they are a lot many options available in the market.  
  •          Managers interested in knowing the relevance of roles in Agile and how they are supposed to be handled- With self organizing Agile teams, the concern for management always lies in where does the existing roles fit in?
Why should you read this book?
Anyone interested to know where a project manager would fit in an Agile Organization can read this book. I have to say, the book is for someone who’s new to Agile, or has been working in traditional project management role for long.  

What’s the price and where can I find it?


Who is the author?
Charles G. Cobb

Waterfall to Agile

Jun 9, 2015 | | 0 comments |
Working in Agile and don't know what to expect? Helping teams self organize but too much push back? 

This e-book is a great resource, read how the experts are doing it around the world one organization at a time.

You can find me on slide 19 and 20. 


Adopting Agile Pt2- Who should be the scrum master?

Dec 3, 2014 | | 0 comments |
A lot of organizations and teams tend to appoint a scrum master for the team, sometimes against the wishes of the individual taking up the role.

I think it beats the purpose of transformation.


Appointing someone for the role can never lead to success. A scrum master as we know plays a crucial role during the transformation, you want someone who is interested, who will put their best foot forward and who’s up for the challenge.

Here are some ways you can look for a scrum master-
  • Provide enough information on what a role of a scrum master is and is expected
  • Talk about benefits of being a scrum master from a career perspective
  • Ensure enough support and training's for the scrum master who will take up the role.
  • Ask for volunteers

 Once you have a pool of volunteers or one per team, you can provide them with training's required to take up the role.

However, this role has its own classic confusion. Should a scrum master be a full time role or should it be part time along with your functional role. Some will have full time scrum master roles and take up multiple teams and some prefer part time scrum masters who are an integral part of the team and also works in their functional role.

I persnally prefer scrum masters who are an integral part of the team and understand the work and ins and out of what’s going in the team.  I also think team members accept scrum masters easily when they are part of the team than someone who is part of multiple teams and is more of a manager with a title of the scrum master.

So, who should really take up the role of a scrum master?
·         Someone interested (there is a learning curve)
·         Has social skills (taking care of impediments requires some)
·         Strong in communications (keeping the team together)
·         Has enough negotiation and convincing skills  (need that to interact with your product owner)
·         Is generally calm and not aggressive (when handling internal team conflicts)
·         Has a sense of humor (helps when dealing with the pressure of juggling roles and rebellious team members)
·         Can think objectively and not take sides
·         Determined to fix issues and keep the team together
·         Ability to think out of the box ( absolutely required when working with a smart competent team)

Well that might seem a lot, the good news is most of us have it in us. We have been trained and retrained to give up a lot over time and that might have clouded our out of the box thinking.  A nudge and encouragement can bring in the creativity back. And it improves with time.

The managers/management need to understand that the role though of a facilitator isn’t easy and needs time to settle in. Team members always don’t make it easy on the scrum master. So, give the time and encourage as much as possible.

Here’s what Mike Cohn says about being a scrum master  and an interesting article that talks about why the projectmanager is not a scrum master


You can read Part 1 of the series here

(Pic courtesy- Google Images)

Adopting Agile Pt 1- Three things to consider when moving into Agile

Nov 20, 2014 | | 0 comments |
Moving into the Agile way of working is a life changing decision.

  • Don’t move to Agile because everyone is- IT’s a trend and everyone is working the Agile way and so should you- is the wrong way to approach Agile. Sometimes even client requests and management interest force team members to move. Changing overnight is tough especially when you have been comfortable working a certain way. If transforming into Agile is the agenda, read some blogs, attend training's, look up articles, ask people who have been working in Agile. Then decide if you really want to make the move and simply start with pilot teams.
  • Don’t look for tools immediately- start slow and stop adopting tools immediately. A white board in the team area will just work fine. If you have distributed teams, use simple tools like Linoit  or Trello .  Tools should encourage more communication not replace it. 
  • Don’t expect a miracle in your first sprint- Make smaller changes before you transform completely, start with a daily standup or writing user stories. Every sprint introduce something new and work within the comfort levels of the team, this will make your new adoption easier than being messier. Not all teams adopt as easily or work as smoothly, what you will notice is more and more internal problems surfacing and that’s a good sign. Try working out the problems and watch the team perform better.  
This is a 5 part series on Adopting Agile. 

(Pic Courtesy- Google images)


Scrum Team has stabilized- what next?

Mar 31, 2014 | | 1 comments |
Most transformations start with the basic idea of either getting teams to start working in Agile or streamlining their existence process.

At a certain point, teams stabilize, velocity improves, quality soars and things look up.

Is the goal to repeat the same cycle day after day or is there more to work through once the team stabilizes? I have always though that the trying to get teams working in Agile is more like a bicycle- if you stop pedaling, it stops.

Here are 5 things to consider as next steps to keep the team going:
  • Baseline velocity- Always know your baseline velocity, when you started and ways you can work on it.
  • Focus factor- when the team stabilizes, it’s a good idea to know if the team has the right focus. Its velocity/work capacity. For more info read Jeff Sutherlands article here .  
  • Failure trends and patterns- The commitment made by the team always doesn't match the outcome. Looking into why stories fail and trying to identify a pattern might lead the team to understand the underlying problem. It could be user stories that require infrastructure, it can be kind of stories that haven’t been worked on, it can be a story requiring a new technology.  Once you have identified the pattern, it becomes quite easy to find a resolution.
  • Estimations- If in every sprint more than 20 percent of stories remain not done, along with other factors you might want to have a look at the way estimation is being done by the team. Some teams commit more by underestimating stories in trying to please the management and keeping to the team’s velocity. Of course by the end of the sprint teams fail to deliver. There are more managers and Product Owners who always push the team to commit more, so they have enough work on hand ever sprint fearing lesser work meaning team members might be free most of the time. Bottom-line, under estimating doesn’t help as much as over estimating doesn't.
  • Linking and tracking the layers- Stop looking only at team levels and start looking at the bigger picture, look into the your program and portfolio management and how it  is coming down to the team. Look into the quality of the user stories and how everything is affecting the team.
(Pic Courtesy: Google Images)

To learn about how to get into project management read my book Stepping into Project Management (Welcome to the #PMOT World). To connect with experienced Project Manager's from all over the world, get mentored or shadow for a day see the SIPM Community.

Interview with Siddharta Govindaraj

Today we interview Siddhartha Govindraj, who specializes in Lean/Agile processes for software development. He has also contributed in the book "Beyond Agile: Tales of Continuous Improvement" published by Modus Cooperandi Press, Feb 2013 and Published in the March 2011 issue of the Cutter IT Journal on "Use of Kanban in Distributed Offshore Environments". An occasional organizer of events as a part of Chennai Agile User Group and speaks in conferences in India and abroad.

He was nominated for the Brickell Key award in 2011, an award given by the Lean Software & Systems Consortium for recognizing achievements in the lean-agile industry and is also a Fellow of the Lean Systems Society.

He is very interested in the behavior of decentralized and distributed systems.

Agile becoming mainstream now, how do you think the world of project management has changed?

In one way, yes….. definitely more and more organizations are seeing the value of agile in terms of incremental development and faster time to market. However, there are a few aspects where agile is still to make a significant mark. First, the people aspect of agile has still not fully permeated into the culture of many organizations. The idea that motivated, self-organized teams can deliver better software is not yet in the mainstream. I also think that many companies need to invest in the technical environment. The third aspect that companies often neglect is looking at delivery as an end to end system in the organization. Agile is often applied at the team level, and systemic impediments are not fixed. So there is still a long way to go. 

While older companies have a tough time with transformation, the good news is that newer companies like Facebook have been agile right from the start. Over the next decade, success of these newer companies will establish the culture for the whole industry.

As someone who creates tools for Agile and Lean project environments, please tell us what according to you is the most important: the tool or the expertise of the project manager?

Of course the expertise of the people in the project is the primary criteria for success. Where tools will help is in aiding decision making so that people (both within the team, and management) have better insights to take better decisions. 

This questions also leads to an interesting difference between agile project management tools and traditional project management tools. In agile, a lot of decisions are taken by the self-organized teams. Hence the tools need to be able to support the needs of the team. If the team decides that the tool is an overhead or is not adding value to them, then it becomes worthless. By contrast, the primary need of traditional tools is targeted towards managers, who are the decision makers to micromanage the team. 

A big problem is when an agile tool is used in a traditional way – i.e. the team does not feel the value, but is forced to use it so that the managers can micromanage them. My personal opinion is that tools that encourage this behavior rarely lead to truly agile culture. 

Tell us why you decided to create your software and did you use agile way of managing it while n development?

The previous answer has some insight into why we launched our tool. We saw that many organizations implemented tools which support agile mechanics, but not the agile mindset. Such tools get deployed, teams hate to use them but are forced to do so because the management doesn't trust the team and wants to control exactly what is going on in the team. Well, guess what? The team only updates the tool rarely and the data is unreliable so it helps nobody. This does not help build an agile culture. 

What we wanted to do was to build a tool that a team will find easy to use and useful for their own self organization. Basically, we took traditional, proven methods that teams use in a physical space -- card walls, task boards, story maps and so on, and made them available in an electronic format. This gives the benefit of electronic tools, while still being in a format that teams find useful for themselves. 

What according to you are the 3 qualities that every Agile Project Manager should have?

First, curiosity to keep learning. Secondly, soft skills to connect with people (within the team and outside) and build relationships. Finally, the ability to influence people and drive change and improvement. 

I haven't said anything about knowledge of agile. This is easy to learn, and anyone can learn what a product backlog is and how a particular process works. But the qualities above are difficult to train, and very crucial for agile success.

If someone new, stepping into Agile Project Management asked you about the 3 books to read, what would you recommend?
My favourite three books are:

1. Agile Software Development -- Alistair Cockburn (Quick note: This book isn’t about agile, but methodologies in general. It’s a great background about how and why agile works, but perhaps not what you are looking for if you want to know specific mechanics like how to story point a story)
2. The principles of product development flow -- Donald Reinertsen 
3. Kanban -- David Anderson

Where can someone find the link to your software and your books?
I've also been a contributor to this book - http://amzn.to/beyond_agile


Thank you very much for your time.