We are starting this new project with a customer and during the envisioning phase someone asked me a question about the Business Analyst being part of the Scrum team. The question was "here we have a BA who needs to work on something during the Sprint, so should she attend the daily stand up calls?" To me the answer is straight ... but let me get that answer to you by using an Agile practice I all as "Ask a Why" (or "Why 5").
So let us ask below questions to ourselves and see if we can get the answers. Is this BA going to work on something
- that is going to affect or contribute to the Sprint Deliverable?
- that may become a bottleneck if not completed?
- that may have some dependency that the Scrum team is going to deliver?
- that scrum team including the product owner will be interested to know the progress on daily basis
If the answer to any or many of above questions is affirmative, then yes the BA should be part of the daily stand up - which also means the BA should be part of the planning meeting, she should have a backlog (as part of your Sprint Backlog), should provide status and report bottlenecks and also attend the retrospective if possible (you never know, the same devil may show up again in some sprint :) ).
The scrum master was intelligent enough to get the answer based on the questions I threw at him and here we are ... working on the Sprint which is going on smooth. And once again "Ask a Why" worked.
Thursday, November 25, 2010
Sunday, June 27, 2010
Is Scrum Master the toughest role of Agile?
For past 2 weeks I am in Boston on a business trip. And on a lonely evening I was just thinking about the change of role that I am experiencing from what I was 5 years back and what I am today.
5 years back, most of me was a Project Manager - busy with managing project, assigning tasks, running behind teams, writing status reports, convincing customers, fighting with management, yada yada yada ... the list just goes on. I dont fully remember how satisfying the days were, but don't even think I had any peaceful days.
Today, most of me is a Scrum Master and let me say "I like it this way". No team to run behind, no customers to fight with, no management disagreement (well, most of the time) and most importanly, I don't have a responsibility ..... wait .. let me take that last one back. "No Responsibility" ... that does not sound right.
And this is the exact thought that struck my mind. Being Scrum Master has eased my day to day life, but has it made me less productive, is it any easy compared to being a Project Manager, has it taken the challenge out of my job ... and many such questions. There as no direct answer, so I had to rewind the 5 years and start from where I had left. A One-on-One comparison of what challenges I had then ... and what challenges I have today. And after a good hour on the thought, the picture was very much clear.
Being Project Manager was easier than being a Scrum Master.
No big deal that I am not in control. All that matters is "Things are still going fine!!"
5 years back, most of me was a Project Manager - busy with managing project, assigning tasks, running behind teams, writing status reports, convincing customers, fighting with management, yada yada yada ... the list just goes on. I dont fully remember how satisfying the days were, but don't even think I had any peaceful days.
Today, most of me is a Scrum Master and let me say "I like it this way". No team to run behind, no customers to fight with, no management disagreement (well, most of the time) and most importanly, I don't have a responsibility ..... wait .. let me take that last one back. "No Responsibility" ... that does not sound right.
And this is the exact thought that struck my mind. Being Scrum Master has eased my day to day life, but has it made me less productive, is it any easy compared to being a Project Manager, has it taken the challenge out of my job ... and many such questions. There as no direct answer, so I had to rewind the 5 years and start from where I had left. A One-on-One comparison of what challenges I had then ... and what challenges I have today. And after a good hour on the thought, the picture was very much clear.
Being Project Manager was easier than being a Scrum Master.
- It was easier to ask a team to do something and push them forward. Believe me, it is very difficult to convince someone to do the right things.
- It was easier to prepare my project plan with my estimates and assign the resources. Believe me, it is very difficult to have every team member get their Sprint Backlogs ready before start of the Sprint.
- It was easier to demand I want it by today evening (max by tomorrow morning). Believe me, it is very difficult to say Alright, do it by tomorrow morning, but ensure it is done.
- It was easier to get the status from team members and present it in the Green Zone to customer. Believe me, it is very difficult see the team exposing the real status on daily basis.
- It was easier to take the project decisions and own them. Believe me, it is very difficult to coach a team to be empowered to take the decisions and respect it, fight with management for protecting the team decisions.
- It was easier to prepare a 6 months /1 year / or longer plans and blame everything on Change Requests. Believe me, it is very difficult to say, changes? so what?
- And many more things .... but the most difficult is to create this fun loving environment, a healthy and faith based work culture with customer and letting it go so that team can manage it. It is just difficult to see stuff not happening the way you like. And it is very difficult to say "team did a great job" knowing that you probably would have done the same way.
No big deal that I am not in control. All that matters is "Things are still going fine!!"
Sunday, June 20, 2010
User Stories or Use Cases
This seems to be the question of the month. I got it quite sometime in last few weeks. So thought of penning some of the discussions, thoughts and research I did on it.
As Dr. Cockburn said it, besides the first three letters, there is nothing common between Use Cases and User Stories.
Use Cases are favorite of the technical world when it comes to capturing the functional requirements. It allows you to capture many details including the functionality, alternate flows, exception conditions, and other things associated with the requirement. And it asks for more detailed analysis and brings a more formal way of capturing the requirements. But a major draw back of Use Cases is it requires you to capture too many details right up front and calls for a good amount of documentation.
User Stories, on the other hand are a very "informal" way of capturing the requirements. It focuses more on the discussion between Developers and Users. It allows you to capture these details without any formality and with clear focus on understanding the requirement as the user will like to see it implemented. To add to the informality associated with user stories, let me mention that many teams use the Story Cards - a complete non-electronic way of capturing the user stories. The beauty of the user stories is it is depicted the way user understands it.
I remember I read it somewhere - the three "C"s of user stories - The Card, The Conversation and the Confirmation.
The CARD is the medium. It is small big enough to write a user story and small enough to keep it short that a developer can implement.
The CONVERSATION is the key aspect of a user story. The story on the card is only the notion and expects the developers that the story is not complete without a Conversation with the user. So get into discussion and get the details you want, only when you are ready to start implementing.
The CONFIRMATION is an agreement between the developer and the user on how the story will be implemented or let us say 'when is it complete'. It is the acceptance criteria or the 'definition of done' for the story on the other side of the card.
Well, the real question still remains - What shall one choose ... User Stories or the Use Cases? What is the criteria?
I think the answer lies in what you need. If your customer expects the very well defined formal documentation, guess your choice is Use Cases. But if you have an opportunity to discuss and work with customers closely and if you are not very keen on very formal documentation, well go for Use Cases. But let me tell you that Agile as such does not stop you from or even recommends against creating Use Cases.
As Dr. Cockburn said it, besides the first three letters, there is nothing common between Use Cases and User Stories.
Use Cases are favorite of the technical world when it comes to capturing the functional requirements. It allows you to capture many details including the functionality, alternate flows, exception conditions, and other things associated with the requirement. And it asks for more detailed analysis and brings a more formal way of capturing the requirements. But a major draw back of Use Cases is it requires you to capture too many details right up front and calls for a good amount of documentation.
User Stories, on the other hand are a very "informal" way of capturing the requirements. It focuses more on the discussion between Developers and Users. It allows you to capture these details without any formality and with clear focus on understanding the requirement as the user will like to see it implemented. To add to the informality associated with user stories, let me mention that many teams use the Story Cards - a complete non-electronic way of capturing the user stories. The beauty of the user stories is it is depicted the way user understands it.
I remember I read it somewhere - the three "C"s of user stories - The Card, The Conversation and the Confirmation.
The CARD is the medium. It is small big enough to write a user story and small enough to keep it short that a developer can implement.
The CONVERSATION is the key aspect of a user story. The story on the card is only the notion and expects the developers that the story is not complete without a Conversation with the user. So get into discussion and get the details you want, only when you are ready to start implementing.
The CONFIRMATION is an agreement between the developer and the user on how the story will be implemented or let us say 'when is it complete'. It is the acceptance criteria or the 'definition of done' for the story on the other side of the card.
Well, the real question still remains - What shall one choose ... User Stories or the Use Cases? What is the criteria?
I think the answer lies in what you need. If your customer expects the very well defined formal documentation, guess your choice is Use Cases. But if you have an opportunity to discuss and work with customers closely and if you are not very keen on very formal documentation, well go for Use Cases. But let me tell you that Agile as such does not stop you from or even recommends against creating Use Cases.
Thursday, June 10, 2010
Certified Scrum Master
Yooohoooooooooo! That’s how I feel after earning my very own Certified ScrumMaster (CSM) certificate.
While working on Agile Scrum for almost 5+ years now, I always wanted to get myself this certification. And it simply feels great to complete it with a commanding score of 96%. Sad part is the 4% I missed on one question is something I always talk about in my Agile trainings and coaching. It was a comfortable exam with some of the tricky ones. But the end is sweet sweat.
While working on Agile Scrum for almost 5+ years now, I always wanted to get myself this certification. And it simply feels great to complete it with a commanding score of 96%. Sad part is the 4% I missed on one question is something I always talk about in my Agile trainings and coaching. It was a comfortable exam with some of the tricky ones. But the end is sweet sweat.
After returning to Mumbai, I searched for the CSM courses and to my surprise, there were no courses conducted in Mumbai. So contacted Pete about the same. Couple of months later, received the course invite happening right here in Mumbai. So got registered, got the real good insight into Pete’s knowledge base, his easy ways of making you understanding and very impressive skills to communicate. 16 hours later it was a great feeling to realize that most of what Pete taught is something I was practicing already. And many new things I learned are very effective. The knowledge from training was immediately useful on the project I was working on.
But that last action was still on me. To go and take the online assessment. Waited for it for 2+ months. Not that I was scared but just that I just could not devote time to take it. Finally just yesterday committed myself to the cause and complete it. A whopping 96% felt really good. And I am officially the Certified Scrum Master now. Visit the link here to check my profile on ScrumAlliance.
Now my eyes are on becoming a Certified Scrum Trainer. I hear that it is a 2-3 year journey after becoming the CSM. Well, who is in a hurry? Do it slow but do it right!
But that last action was still on me. To go and take the online assessment. Waited for it for 2+ months. Not that I was scared but just that I just could not devote time to take it. Finally just yesterday committed myself to the cause and complete it. A whopping 96% felt really good. And I am officially the Certified Scrum Master now. Visit the link here to check my profile on ScrumAlliance.
Now my eyes are on becoming a Certified Scrum Trainer. I hear that it is a 2-3 year journey after becoming the CSM. Well, who is in a hurry? Do it slow but do it right!
Thursday, April 01, 2010
Agile Appraisals
Performance Appraisals have become the irreplaceable parts of organizational operational processes and very much for a reason. Come April and all discussion topics on operation floor reduce to just Appraisal. Everyone tends to forget how badly did they perform throughout the year and all of a sudden there is a heavy crop of all the good work that each of us have done. Everyone believes s/he is the start performer of the year irrespective of all the screw ups during the year. Loads of Appraisal forms are printed and hours of time is invested in filling the applications. In all this, one important point that everyone tends to overlook is that Appraisal Ratings are not assigned overnight by the reporting manager, but are accumulated over the period based on your own performance. However if you are thinking the accumulation period is last one year or so, then you are wrong. As a matter of fact, appraisals are based on your performance for last 3-4 months only. Pull any of your own appraisals to date and check it against your performance. I bet my breath on it that you would just not find any match between your rating and your performance at the beginning of the year. As a matter of fact, some excellent accomplishment at the beginning of the year must have been considered to be an obvious thing … you know call of the duty or that is what is expected from your role anyways. But you turn a bad situation into good one or vice a versa in just last 3-4 months and you would find yourself in a sweet spot.
This has worked for organizations for long time. However there are critical issues with the process. One we just talked about, but the most critical one being the traditional appraisals are very influence driven. Most of these appraisals do not talk about your performance, but of what your reporting manager thinks about you. The ratings are a matter of Bargain – you think you need 8, I think you deserve 5, so let us settle for a 6 or a 7. Come on, if you as a reporting manager believe I deserve a 5 then why not stick to your guns? Or are you not so sure about it? The process is not very transparent and also is influenced by the sense of superiority – if you know what I mean. Another big issue is that the traditional method is based on the objectives or Key Result Areas, that are defined at the beginning of the year. But how many times are these KRAs or objectives practical and that to for the entire duration of year. You think the KRAs will be static for the rest of the year ….. Give me a break.
Agility looks at the appraisal process a little differently. We all know that Agility is about team work, about ownership and about empowerment. So it puts the appraisal process in employees' hands. With Agile, the boundaries of roles of Resource and Reporting Manager get erased, and as a result the traditional appraisal system finds itself in nowhere-land.
Agile proposes a flat team structure without any reporting authorities and with equal responsibilities. Project success or failure is a team effort and individual performances become a part of history. And therefore it becomes very much important, for all the HR representatives at least, to brain storm on a new way of appraising the Agile Teams. Couple of options I could think of are:
1. Celebrate and/or punish entire Team’s (non)Performance. Treat and rate every individual the uniform way. So each of us gets the same raise or no one gets it. The challenge here is – no matter how much we read that it is all about team performance, it is rare that a team is successful without individual heroes. And we risk of frustrating these individual performers by putting them at the same table as that of low performers. (Another school of thought here is if an individual thinks s/he is smarter than rest of the team, s/he is not fit to be on an Agile team anyways).
2. Another better way is to have Scrum Master do the appraisals in discussion with entire team. This may work where a Project Manager is pretending to be the Scrum Master. But Scrum Master by definition is not in position for this job.
3. The third and the best way, at least according to me, is to let the teams conduct appraisals internally for everyone. The way it should be done is:
- Each team members appraises every other member on three aspects (there is no need to weight any of these aspects separately as all of them are equally important)
- Technical
- Soft Skills
- Team Player
- Alignment towards Organizational values / growth
- Average the ratings given by rest of the team to get individual’s rating (and be sure to adjust the outliers by discussion)
- Apply the Project Success Factor (PSF) to individual’s rating to flatten it at organizational level. PSF could be as simple as the impression of Senior Management or as complex as special derivative of various factors including Project Profitability, Schedule Variance, Resource Maturity Index, Customer Satisfaction Index, etc. The PSF would be equally applicable to each of the team members.
- The key is to gather multiple data points. So just like frequent sprints, gather the data points every quarter (or at the end of the project if project is of small duration).
My point of view, option 3 this is the most agile way appraising individuals and teams – irrespective of the project methodology. It will ensure the individuals are rated properly, will maintain the organizational harmony during and after the process and most importantly will enforce the team spirit and team work in individuals. After all, you just don’t have to behave with your Reporting Manager, but also respect your team members.
Let me know if you have a better way than this. Did I hear “Scrap the appraisals”?
Wednesday, March 24, 2010
Transitioning to Agile: Step 1 | Learn the “Shu - Ha – Ri” Journey
The basis of all Agile Methodologies is the principle of Adptation – the ability to adjust to change. Being Agile is about learning from the experience and improving based on the same. It is a simple and continuous process of learning and improvement. And as that of any Learning Process, transitioning to Agile follows steps of Shu, Ha, Ri.
Dr. Alistair Cockburn explains this very nicely in his video on “I am here to burry Agile”. As he explains it, the learning is a three step process. Human behavior is to resist a change. To break the shackles of the comfort zone and accept new challenge requires a specific mindset (of which I will talk separately in another blog), which in particular is hard to find. And this exactly is the thing that we need to attack when it comes to transitioning to Agile.
The process of learning is rather progressive one than the aggressive. The progressive learning goes through a defined structure of knowledge capturing, improving and excelling. Alistair puts it using the Japanese terms Shu, Ha and Ri.
“Shu” is the state where we learn something new. The mind is open for ideas and we only focus on capturing the knowledge. We learn by books and practice as stated. The boundaries of curiosity are narrow and focused on what we see. It is a state where the mind is accepting the change.
Once the change is set, we move into the “Ha” state, where what we learn is not sufficient. The curiosity kicks in hard and the mind looks for additional sources and ways of information. Everything adds to what we have learnt so far. This is the state where we want to Explore ideas. The success and failure of experiments add to and enriches the knowledge.
Then comes the “Ri” state where the mind questions what we know. It challenges us to excel and put the excellence to test. The knowledge from various sources and the experience from various experiments forces the new definitions of knowledge. We tend to build new stuff using what we know and learn from it. The “Ri” state brings in invention to what we have learnt in “Shu” state and what we had excelled in “Ha” state.
I put this as the 3Es – Experiment, Explore and Excel. “Knowledge of Application” and “Application of Knowledge” is another way to put the same. “Knowledge of Application” is where we learn about the stuff – the Shu and Ha phase, where as “Application of Knowledge” is putting the knowledge to test which is the later of Ha and Ri phase.
Dr. Alistair Cockburn explains this very nicely in his video on “I am here to burry Agile”. As he explains it, the learning is a three step process. Human behavior is to resist a change. To break the shackles of the comfort zone and accept new challenge requires a specific mindset (of which I will talk separately in another blog), which in particular is hard to find. And this exactly is the thing that we need to attack when it comes to transitioning to Agile.
The process of learning is rather progressive one than the aggressive. The progressive learning goes through a defined structure of knowledge capturing, improving and excelling. Alistair puts it using the Japanese terms Shu, Ha and Ri.
“Shu” is the state where we learn something new. The mind is open for ideas and we only focus on capturing the knowledge. We learn by books and practice as stated. The boundaries of curiosity are narrow and focused on what we see. It is a state where the mind is accepting the change.
Once the change is set, we move into the “Ha” state, where what we learn is not sufficient. The curiosity kicks in hard and the mind looks for additional sources and ways of information. Everything adds to what we have learnt so far. This is the state where we want to Explore ideas. The success and failure of experiments add to and enriches the knowledge.
Then comes the “Ri” state where the mind questions what we know. It challenges us to excel and put the excellence to test. The knowledge from various sources and the experience from various experiments forces the new definitions of knowledge. We tend to build new stuff using what we know and learn from it. The “Ri” state brings in invention to what we have learnt in “Shu” state and what we had excelled in “Ha” state.
I put this as the 3Es – Experiment, Explore and Excel. “Knowledge of Application” and “Application of Knowledge” is another way to put the same. “Knowledge of Application” is where we learn about the stuff – the Shu and Ha phase, where as “Application of Knowledge” is putting the knowledge to test which is the later of Ha and Ri phase.
Tuesday, March 09, 2010
(Why) Do You Agile?
"Do You Agile?" is my signature tag these days. And for a good reason - I have seen Agile in action and working. But very recently my own tag line was thrown back to me with a twist - "WHY do you agile?"
We were working on a proposal for one of our customers. And discussion was on regarding the “proposed project management methodology”. I couldn't help but put my DNA on the table. And proposed Agile. Bang …. there came the unwanted (well, at least for me) one ... "Why do you propose Agile ..... JUST BECAUSE YOU LIKE IT". Man that was some strong emotion there. But I was so engraved in detailing the DNA, I could not focus and react to the it than just replying with a smile. But know what …. the smile said everything.
First Agile helps me to make sure “we deliver what our customer needs" with very little waste of efforts. After establishing a faith-based healthy work environment, things just happen to fall in place. Issues are no more issues and difference-of-opinions are opportunities to collaborate and improve. One one or two, but I have seen this working with every customer I have worked with. All you need is that 5 letter F word ... FAITH am talking about.
Second Agile helps me nurture the "true excellence" in my team. There wasn't a day when I was not behind individuals checking how things were, worrying about how everyone was doing, thinking who should do what and and visualizing how is my MPP looking today - when I was the project manager. But the day I became the Scrum Master, with a lot of pain of losing the control, I realized the change was for the betterment. Really .... you dont have to control your team. Rather its the team that drives and controls the project better than a Project Manager.
Third I dont have to worry about screwing the project up by underdelivering or over burning the budget and resources. With the Prioritized backlog and well estimated Sprint backlog, there was little chance of underdelivering and burning up all my oil. Rather with customer in driving seat for the requirements and Sprint priorities, my life was much easier and limited to focusing just for next two weeks of work. It is easier to take care of pennies than pound you know. And who does not want to do little and gain big. Dont know about you, but I sure do!
Fourth I was tired of communicating the untrue status every Friday. It was hard to enjoy a weekend with a heavy heart. After practising "Honesty is the policy" all my school life, it was hard to digest the fact that I was smiling after sending an untrue status report. I mean how much can one manipulate to avoid a backlash from the customer and / or senior management. I was really done with it. So the candid and open communication channels gave way to my true self. Thanks God Its Friday.
Next is big one. Man I was so tired of trying to make both ends meet when it came to Change Requests. Endless discussions of justifying change requests and defects (that were actually not defects) just exhausted me. With Agile when customer knows what is going on daily basis - what each member is working on and what the daily work is producing, there is a little opportunity for them to complain later that this is not what I wanted and very little opportunity for me to say this will cost you extra. Well, I still need to bother for this on a fixed cost project when the initial scope was not known, but you know it is easier to sort this way than earlier one.
And umpteenth time, a sense of satisfaction after seeing your team living to their commitments, a sense of pride when the burndown burns right on that red dot of last day of sprint, a feeling of joy when customer says "Accepted" on every commitment the team had made, and a sense of self-liking when team members strive to improve in those retrospective - that all is more than sufficient for me to Agile whenever I can.
So there is the answer of confidence .... "Yes I Agile because I like it because it works because it is meant to be!" ….. Amen!
We were working on a proposal for one of our customers. And discussion was on regarding the “proposed project management methodology”. I couldn't help but put my DNA on the table. And proposed Agile. Bang …. there came the unwanted (well, at least for me) one ... "Why do you propose Agile ..... JUST BECAUSE YOU LIKE IT". Man that was some strong emotion there. But I was so engraved in detailing the DNA, I could not focus and react to the it than just replying with a smile. But know what …. the smile said everything.
First Agile helps me to make sure “we deliver what our customer needs" with very little waste of efforts. After establishing a faith-based healthy work environment, things just happen to fall in place. Issues are no more issues and difference-of-opinions are opportunities to collaborate and improve. One one or two, but I have seen this working with every customer I have worked with. All you need is that 5 letter F word ... FAITH am talking about.
Second Agile helps me nurture the "true excellence" in my team. There wasn't a day when I was not behind individuals checking how things were, worrying about how everyone was doing, thinking who should do what and and visualizing how is my MPP looking today - when I was the project manager. But the day I became the Scrum Master, with a lot of pain of losing the control, I realized the change was for the betterment. Really .... you dont have to control your team. Rather its the team that drives and controls the project better than a Project Manager.
Third I dont have to worry about screwing the project up by underdelivering or over burning the budget and resources. With the Prioritized backlog and well estimated Sprint backlog, there was little chance of underdelivering and burning up all my oil. Rather with customer in driving seat for the requirements and Sprint priorities, my life was much easier and limited to focusing just for next two weeks of work. It is easier to take care of pennies than pound you know. And who does not want to do little and gain big. Dont know about you, but I sure do!
Fourth I was tired of communicating the untrue status every Friday. It was hard to enjoy a weekend with a heavy heart. After practising "Honesty is the policy" all my school life, it was hard to digest the fact that I was smiling after sending an untrue status report. I mean how much can one manipulate to avoid a backlash from the customer and / or senior management. I was really done with it. So the candid and open communication channels gave way to my true self. Thanks God Its Friday.
Next is big one. Man I was so tired of trying to make both ends meet when it came to Change Requests. Endless discussions of justifying change requests and defects (that were actually not defects) just exhausted me. With Agile when customer knows what is going on daily basis - what each member is working on and what the daily work is producing, there is a little opportunity for them to complain later that this is not what I wanted and very little opportunity for me to say this will cost you extra. Well, I still need to bother for this on a fixed cost project when the initial scope was not known, but you know it is easier to sort this way than earlier one.
And umpteenth time, a sense of satisfaction after seeing your team living to their commitments, a sense of pride when the burndown burns right on that red dot of last day of sprint, a feeling of joy when customer says "Accepted" on every commitment the team had made, and a sense of self-liking when team members strive to improve in those retrospective - that all is more than sufficient for me to Agile whenever I can.
So there is the answer of confidence .... "Yes I Agile because I like it because it works because it is meant to be!" ….. Amen!
Thursday, January 07, 2010
Agility as Behavior
I speak with people, attend discussions on Agile and Lean and also conduct trainings on Agility with focus on Scrum and Lean Thinking. People are quite enthused and interested for what it brings to those tired brains of Waterfall.
After working for a Project Manager than working for a Customer, after doing the things that Project Manager needs than the project or customer needs, and doing the way the Technical Lead sees rather than how User Sees it - and that to over and over again - one surely is bound to be tired. I mean; I surely would. So my crash course with a quick introduction to Agile Manifesto, with Agile offering so much of freedom and offerings at a little cost of ownership, commitment and discipline, people are very much enthused about working on the Agile Project.
Most of the trainings goes in understanding Agile, comparing and matching it with Waterfall and dreaming of how will it be to work on an Agile project. But it enters a silent thinking zone when I mention "Agility is NOT a methodology .... It's the Behavior for an Individual and Culture for an Organization".
Hold on ... I understand how you feel .... and thank you for agreeing with me. But for those who are still in doubt, please read on and let me know what you think.
Agility is not about executing the project in iterations, delivering value to customer or owning the work and living the project commitment. It is not about contributing to the Product Backlog or completing the Sprint backlog, neither is it about getting on that 10 minute stand up meeting. Agility is not about delivering As Fast As Possible and definitely not about working with the team and customers.
However it has more to do with the mindset than the practices. It is that voluntary drive within which will force you to think of Customer and the Value, provide a sense of Pride of Owning the Work and Living the Commitments, the fire to learn and improve by Collaboration and Experimentation, the flexibility to Adapt for Changing Environment, the Self-managing DNA set that continuously Ask A Why in order to find the optimal way (not the best possible one), the Brain Cells that prefers the Human Aspect as opposed to mechanical processes, a Common Sense that would ask you to go-talk-in-person than sending an email or other passive communications.
And all this if is not behavior than what is? An agile individual would always be agile and lean - no matter if that's her professional life or personal.
--------------------------------------------
Now talking about Organizational Cultures, Organizations are made of and run by individuals. Physics states - the material is made of atoms - the Organizational culture is commulitive behavior individuals working in it.
For an organization to be Lean and/or Agile, it is not sufficient to know the Agile Principle or starting initiatives. It is up to the individuals to live up to the Lean Principles. In everything they do and every minute they spend at the work, the individuals should breath and live by principles of eliminating waste, exercising the empowered rights and seeking improvement of work, work place and organization. An organization can not claim to be Lean and its floor is all cluttered with unclaimed printed waste at printer desks or has processes that become bottleneck for employees to complete their work. This is more explicit for a Software Development organization where the PDLC and PMLC processes become mandatory road blocks than facilitating the productivity improvement.
For example, for decades now, Review Processes are considered to be irreplaceable tools for Quality Assurance and Improvement. Like the code review which leads to collection of various metrics data. In the first place, Lean calls Review process as one of the Wastes. Plus, at organizations require reviewers to log defects for A. analysis of defects for defect prevention which is a good practice and B. it is required by organizational process for ISO and other certification compliance. The organization here is fouling the Lean Agility principles to a very great extent.
For an agile individual, both of above cases (A and B) are a little weird and useless. The Review process in this case should be used to improve one's coding practice and proactively avoid defects - like Pair Reviews which expects fixing of defects immediately and logging only the complex defects which can require a little more analysis (more on effective coding practices in some other blog later).
So basically the Organizational Processes - be it PDLC, PMLC or HR, Admin or support processes - should be focused around A. Facilitating and not binding B. Enable Improving and not evaluating C. Voluntary and not forced D. Flexible and not Rigid E. Evolving and not Defined -- which will lead to a Agile individuals and in turn a Lean Organization.
And therefore Agility is purely a culture for an organisation adopted from individual behaviors of its employees.
After working for a Project Manager than working for a Customer, after doing the things that Project Manager needs than the project or customer needs, and doing the way the Technical Lead sees rather than how User Sees it - and that to over and over again - one surely is bound to be tired. I mean; I surely would. So my crash course with a quick introduction to Agile Manifesto, with Agile offering so much of freedom and offerings at a little cost of ownership, commitment and discipline, people are very much enthused about working on the Agile Project.
Most of the trainings goes in understanding Agile, comparing and matching it with Waterfall and dreaming of how will it be to work on an Agile project. But it enters a silent thinking zone when I mention "Agility is NOT a methodology .... It's the Behavior for an Individual and Culture for an Organization".
Hold on ... I understand how you feel .... and thank you for agreeing with me. But for those who are still in doubt, please read on and let me know what you think.
Agility is not about executing the project in iterations, delivering value to customer or owning the work and living the project commitment. It is not about contributing to the Product Backlog or completing the Sprint backlog, neither is it about getting on that 10 minute stand up meeting. Agility is not about delivering As Fast As Possible and definitely not about working with the team and customers.
However it has more to do with the mindset than the practices. It is that voluntary drive within which will force you to think of Customer and the Value, provide a sense of Pride of Owning the Work and Living the Commitments, the fire to learn and improve by Collaboration and Experimentation, the flexibility to Adapt for Changing Environment, the Self-managing DNA set that continuously Ask A Why in order to find the optimal way (not the best possible one), the Brain Cells that prefers the Human Aspect as opposed to mechanical processes, a Common Sense that would ask you to go-talk-in-person than sending an email or other passive communications.
And all this if is not behavior than what is? An agile individual would always be agile and lean - no matter if that's her professional life or personal.
--------------------------------------------
Now talking about Organizational Cultures, Organizations are made of and run by individuals. Physics states - the material is made of atoms - the Organizational culture is commulitive behavior individuals working in it.
For an organization to be Lean and/or Agile, it is not sufficient to know the Agile Principle or starting initiatives. It is up to the individuals to live up to the Lean Principles. In everything they do and every minute they spend at the work, the individuals should breath and live by principles of eliminating waste, exercising the empowered rights and seeking improvement of work, work place and organization. An organization can not claim to be Lean and its floor is all cluttered with unclaimed printed waste at printer desks or has processes that become bottleneck for employees to complete their work. This is more explicit for a Software Development organization where the PDLC and PMLC processes become mandatory road blocks than facilitating the productivity improvement.
For example, for decades now, Review Processes are considered to be irreplaceable tools for Quality Assurance and Improvement. Like the code review which leads to collection of various metrics data. In the first place, Lean calls Review process as one of the Wastes. Plus, at organizations require reviewers to log defects for A. analysis of defects for defect prevention which is a good practice and B. it is required by organizational process for ISO and other certification compliance. The organization here is fouling the Lean Agility principles to a very great extent.
For an agile individual, both of above cases (A and B) are a little weird and useless. The Review process in this case should be used to improve one's coding practice and proactively avoid defects - like Pair Reviews which expects fixing of defects immediately and logging only the complex defects which can require a little more analysis (more on effective coding practices in some other blog later).
So basically the Organizational Processes - be it PDLC, PMLC or HR, Admin or support processes - should be focused around A. Facilitating and not binding B. Enable Improving and not evaluating C. Voluntary and not forced D. Flexible and not Rigid E. Evolving and not Defined -- which will lead to a Agile individuals and in turn a Lean Organization.
And therefore Agility is purely a culture for an organisation adopted from individual behaviors of its employees.
Wednesday, January 06, 2010
Agility and Me
About 5 years back, I met this new thing called "Agile". New - not because it was fresh from oven and smelling fresh ...but because I was looking at it first time. And 5 years on, looked at it again and again and yet again, now I live it.
However today is the first time I am writing about it. I plan to do so more often as and when I read or understand more of it. So this first blog on Agility dedicated to myself for being an "Agile Individual"
My personal belief is that Agility is not a methodology ... but is the Behavior for an Individual and Culture for an Organization. I would write more on this some other day, but with this self-belief I look at every Agile methodology ... be in Scrum, Kanban, ScrumBan, TDD, ATDD, FDD, SF, Play Ball ... or for that matter XP.
After swimming in SCRUM world for a long time, I am getting acquainted to Poppendieck, and Cockburns and Shalloways and Andersons of Lean and Agile Community. Kanban, ATDD and Lean Agile interest me the most. SCRUM by experience and others by knowledge are far more better, capable and efficient methodologies as opposed to traditional Waterfall. Not to forget, it is Waterfall only that taught us how not to execute the projects ... so not too much criticism about it either.
Anyways, enough for a quick thing and will jump into more details of Agility in next blog ... so keep well till then ... and I promise, wont keep you waiting for long.
Subscribe to:
Posts (Atom)