1. Senior Management
Agile is a silver bullet that will fix all issues is a myth. But Senior Management perceive this as fact. Agile and its frameworks have a great knack of bringing forward hidden organization issues like tendency to command and control, developers/testers taking short cut to quality, less focus & preparedness to test automation etc. Agile need for cross-functional roles and collaboration within the company can create issues in strictly functional organization structures. Companies need to adopt matrix structure
2. Senior and Middle Management
Their affinity towards metrics to compare productivity between different teams or an attempt to measure productivity at individual level may derail your agile efforts as it can be easily misinterpreted by teams and can work against Agile values.
3. Project Manager
Given focus on transparency and on pushing responsibility to the team, the Project Manager will be less of a task manager, and more of a problem solver, and will have to “let go” of a lot of previously held control. There is an increased emphasis on honesty, openness, and trust that may feel very different. Operating in an adaptive planning environment will feel very uncomfortable to many.
Project Manager skills shift notably. The focus shifts to be more outward, to the business. Managers must have more polished skills of expectation management with business, as there is much more frequent interaction and transparency. Relationship skills are more important than being a hard task-master. The Manager will shift ownership to his team and focus less on “command and control” and more on teams’ skills of working with the business.
Project Mangers with agile mindset and experience either take up Scrum Master Role or as Agile Coach or remain as Project Managers as there are other responsibilities like budgeting, resourcing, contracting, pre-sales, hiring, program management, account management etc which they can take up. In-fact Agile gives very good platform for middle management to explore and experience new skills.
4. Product Manager
Playing this role becomes tough particularly if you need to play both Product Owner (inward facing) and Product Manager (outward facing) role. Agile increased focus on collaboration and customer involvement asks for product owner proximity to clients and more engagement with users. Need for guidance, good training & coaching becomes dire need to produce mature product owners and helps them in playing this role effectively without putting team at risk.
5. Developer
Developers will work hand in hand with testers and cannot declare a piece of code “done” until the tester gives the green light. Also developers need to assist testers in finishing testing by themselves testing and help the team in achieving sprint goals. Hence developers no more can wash their hands-off by just writing code. It is their responsibility to see it through till end
6. Tester
Testers who are used to having a more clearly specified set of requirements will struggle, as the Agile tester role involves more thought, planning, and business knowledge. The tester becomes a true partner with the developers in building the application. Testers focus moves away from logging bugs, to work with developers and business to build a great high quality product. No more Them vs I divide.
Testers proximity to the product and the need to acquire very good domain knowledge makes them strong contenders for product management roles in the future.
7. Business Analyst(BA)
Working just in time on requirements will feel very unnatural. Working hand in hand with developers to define requirements and then to help test them will feel very foreign. BA has to acquire new skills like backlog grooming, writing user stories, writing/reviewing acceptance criteria etc and need to interact with PO, developers, testers & technical writers quite often.
Business analyst from past era can either grow into Product Manager or act as team members and in rare cases act as proxy product owner. Proxy product owner role is a trap and hence need to be very careful in taking up this role.
8. Technical Lead
In Agile the technical lead has a lot of freedom to decide the level of depth to go to for. Some technical leads may not have sufficient experience to comfortably operate in this more ambiguous situation. Technical Leads will also need to support their teams more with challenging concepts such as Test Driven Development.
Having great Agile leader at Senior Management, good agile project managers at middle layer and team oriented developers is the key to successful transformation.
“Follow Agile” mindset will only help you get into the water, but “Being Agile” mindset will help you swim in the current.
Like the post.
Not sure of the working on the first point, I don’t think perception of agile as a silver bullet that will fix all issues is a myth. I think that perception is well and truly alive. The myth is that agile is a silver bullet will will fix all issues is the myth.
Cheers
Tony,
Even I meant the same as what you have understood. Probably I should modify that sentence to make it clear. I will do it now. Thanks for coming here and sharing your thought.
Thanks,
Avie
Hi Avienaash,
Your first point reminds me of a post I’ve published nearly a year ago: Agile is not a silver bullet: http://www.pmhut.com/agile-is-not-a-silver-bullet
I like how you explain Agile from each role’s perspective.
PS: I would love to republish your post on PM Hut, where many project managers will benefit from it. Please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.
I can send you abstract of this post which you can publish giving credit to me and then you can add link to my blog post for full read. Let me know if this is fine with you.
Thanks,
Avienaash
Excellent Post, Avienaash!
I appreciate your collation of diversified Agile Concepts in such a straight and simple way.
Kudos,
Amit Gupta
Thanks Amit. Glad to see you here.
Hi Avie,
Very perceptive and detailed article on the role wise mindset change, kudos.
This brings to mind a question, put to me by a fellow PMP. While the basic premise here is for the team to become generalising specialists and all pull as one to get all the stories to done done, could you please share your insights on how one should perform a performance appraisal and provide appropriate ratings during the annual appraisal? Apparently, conducting this excercise for a high performing team of 6 is proving to be a challenge.
Performance appraisals takes a different path for agile teams. Agile is more about team collaboration to build exceptional product.
Hence I would suggest to take this approach.
1. Define team goals and make it same for all
2. Define individual development goals like taking lead on building a new theme to the product, some trainings etc.
3. Have more informal 360 degree feedback involving whole Scrum team, SM and PO for individual performance. Do it outside formal review process and very frequently
4. See if you could define traits, characteristics and behaviors for facilitating team behavior and evaluate them on this
All but the very most incompetent managers know which of their employees are the top performers and which are the bottom feeders. Make sure your one or two true stars are kept happy, and you deal with your one or two laggards.
Each company in the context of agile have to derive their own parameters. Every measurement which you want to do, ask yourself this question “Does this violate agile principles”. If organization is truly agile in thinking from top to bottom, then improvising on your start is easy and easy to convince your HR department on this new process. Is your HR team aware of agile? They should know what is expected of agile teams to accept this.
Hope this helps. Do share if you have tried something and outcome of your experiment. I would be very eager to hear from you.
Thanks and I really appreciate you dropping in here.
Avienaash
Hi Avienaash!
Great post!
Thanks Obaid.
Great Post Avienaash. But there is one specific mindset shift that I am dealing with currently in my project. My team which was using Waterfall model so far, has just adopted Agile delivery model. While estimating stories, they still think in terms of No of hrs. The idea of relative sizing is somehow not going down very well. Or even during relative sizing, team is showing the tendency of first calculating size in hours and then translating that to relative size. Any thoughts on how to deal with this?
Thanks,
Chinmay
You have to strongly facilitate such meetings to make people think or ask “How much time this tory is bigger than that?” Also have they understood this thinking well? Sizing is very powerful, but you should why we are using it to solve what problem and when to use it and when not to use it. My earlier posts on this might come helpful. Go and search story points and you might get few posts on my blog.