Skip to main content

Agile coaching hints

boring stand-ups
  • typical reason: every team member is solving very different issue, no intersections or direct collaboration; basically "I do not care" about 1 status sentence of my colleagues because there is no connection to my current work + strong individualism
  • possible solution: moving towards to the feature team, e.g. instead of doing 1 feature by 1 developer 6 weeks, try to split work and do it in parallel by 3+ developers with feature lead in 2 weeks or even faster if possible (could be challenging at the beginning but helps to build no siloed knowledge) + build the team
too long stand-ups
  • typical reason: too much details + bike-shading and direct follow ups on stand-up with whole team + manager's hijacking
  • possible solution: park every discussion longer than 1 minute after the stand-up and follow up only with committed people (pigs & chickens); 'kill' any bike-shading; have manager's talk after the stand-up
non realistic estimations
  • typical reason: unknown domain or code, in this case it is more about the code + just shallow involvement of the team
  • possible solution: introduce team architect role (hat) and go deep into the code + team grooming culture with proper story mapping since beginning of the project
confusion & misunderstanding about SCRUM
  • typical reason: no real experience from working SCRUM team
  • possible solution: build agile fluency on team level which makes sense, step-by-step
too many task switches and distraction during the sprint which leads to slow development
  • typical reason: sprint shield does not work, priorities are changing like crazy
  • possible solution: empower ScM role to protect the sprint (first question: could we plan for it for the next sprint?), PO works on grooming/planning to order priorities/dependencies and keeps team focused on that 20% of work which delivers 80% of business value
retrospectives does not exists
  • typical reason: underestimation of human nature to learn & improve by simple sharing of different perspective
  • possible solution: create 'room' for regular team retrospective, listen & act, pick 1 or 2 most important topics for the team and focus on them in next iteration/s with help of management if necessary; after 3-6 month look back and evaluate if we are really learning & improving (then celebrate)
busy business
  • typical reason: everybody is trapped in magic wheel, doing best effort work, overloaded by operational stress without any chance to escape
  • possible solution: step back little bit and think, it is about mindset; individual cannot save whole organization or team, act like jazz band - play your part but listen to each other and create together; on individual base act like snooker player - prefer shot which gives you better position in next move over quick win without future
nobody owns the code
  • typical reason: long and legacy development by hundreds of people with too many organizational changes
  • possible solution: introduce (step-by-step) team ownership for particular module (cf. Conway's law), team should pick module - typical bottom up attitude
we are not able to achieve mid-term plan
  • typical reason: plan is unreal and there is not confidence and commitment from the team to it
  • possible solution: planning is good but we have to be ready to change it in order to reflect the reality - review & adjust; it is easier to get commitment for good plan but of course it is necessary to distinguish commitment and forecast
boring meetings
  • typical reason: goal of the meeting is not clear for everybody or meeting is hijacked by another agenda
  • possible solution: consider who & why must be on the meeting, set expectation how & why people should contribute, stick to agenda and park side talks to another time
we are delivering scope not value (benefit)
  • typical reason: we do not measure value (benefit)
  • possible solution: implement analytics & feedback to measure value we are delivering
no motivation
  • typical reason: global & local strategy is not communicated well or does not exists or is not aligned with personal motivation
  • possible solution: clarify global & local strategy and make sure that everybody can understand and align with it if possible
engineering standpoint is not visible
  • typical reason: engineers trying to guess managers thinking and prepare solution which could go
  • possible solution: engineers prepare suggestion which is best according them and clarify why (SWOT) and also they identify other options to support informed decision; decision should be documented and discussed on project retrospective to learn
stand-up does not occur when ScM or PO is not there
  • typical reason: team is not mature enough
  • possible solution: coach the team to take responsibility for a sprint
people are late for meetings
  • typical reason: passive-aggressive behavior = people are not happy to attend meeting but they openly do not rise any objections
  • possible solution: start on time, waiting is waste; talk to people on retrospective how to make less meetings or do it more attractive and try to motivate by setting clear reasons & expectation 'why to attend'

Comments

Post a Comment

Popular posts from this blog

Senior or Junior

Usually companies call young employees Juniors and more experienced Seniors. Sometimes you need to just sit and wait and it will come. Sooner or later. From my point of view it is not enough. I met a lot of old employees they call themselves Seniors but they behave like Juniors. So I defined my point of view on Seniority: professional simple understand what I am doing and understand reason why I am doing it can coach others this is very basic; who can coach others is just fine but who can coach others to became a new coaches is super not genius but have deep knowledge on some specialized parts geniality is overestimated, we do not need "magical guru", to be expert is good enough; if you are "one to go" when there is problem, it is OK big picture overview it is not probably possible to understand a whole system in details but it is necessary to have at least overview know what I know and know what I do not know to see myself in correct light is very
Post a Comment
Read more

Software Engineer

Recently my company expanded the Software Engineer positions in my team. This leads me to thinking about the skills which are necessary for these positions. So I prepared a list of qualities which I think are important for a good Software Engineer. Abstract concept modelling This is essential and there is no room for discussion on this because this is what we do. Love to code It does not matter if you are 15 or 50 or if you write code 10% or 90% of your time, code writing is crucial. Team player The surgeon style teams (one genius with helpers) are obsolete, I prefer real team players who are able to work towards a common goal and share responsibilities. Communicative Silent geeks siting in the corner with a notebook on their knees are not cool any more, we need to talk to each other, we need to be able explain technical stuff to non technical managers, we need to be able to choose the right phrase at the right time. Take responsibility There is no quali
Post a Comment
Read more

Anti-Lean Quotes

Set of quotes which usually highlights Anti-Lean behavior Create waste instead of Eliminate waste ' Developer who is not working at least on 4 projects is not properly utilized ' - less is definitely more and only done-done work counts by end of the day, limited work in progress is helping to focus on right priorities ' In case of any network issues please create a ticket on the help desk system at our partner's web-page' - creating catch 22 situations by design is craziness, such a process does not make any sense 'Yes, this is what our customers really need but could we add also this small feature, just in the case?' - extra feature creates an extra complexity, it is better to stay focused on real value and make it great for the users ' I know that you are working on the top priority but I am sure that you can do also this small task till noon' - probably there will be nothing really done by noon, task switching is more expensiv
Post a Comment
Read more

Scrum rollout

Would you like to start with Scrum in your team? These are few hints from my experience how to make this process smooth, iterative & incremental: get commitment from the management & team define reason: why would you like to do Scrum? what problems it should solve for you? start with simple Kanban in one team: it is easier, you just need to manage 3 lists: backlog (todo), work in progress and done  focus on right priorities of backlog - person who defines the priorities will be 'product owner' setup quick way how to track work in progress and indicate 'impediments' -> daily stand-up; max 15 minutes meeting every day - moderator of the meeting will be 'scrum master', he will be also responsible for solving the 'impediments' focus on dependencies between the tasks to avoid 'impediments' start to put 'discoveries' into the backlog to pre-analyze tasks; discoveries should be done by architect or analyst what is the busi
Post a Comment
Read more

Agile is not a religion

It is quite annoying to me when argument during discussion is like this:  it must be XY because the book says it. It is kind of: Bible is saying XY so we have to follow = end of discussion.  I am not very happy in such a case because we probably do not understand principles and just trying to blindly imitate something without deep knowledge of the matter. I prefer to admit it or show personal standpoint.
Post a Comment
Read more