Tag Archives: agile

[2024 dev2next] reclaiming agility

Posted on by
Reply

Speaker: Dave Thomas @pragdave

For more see the table of contents

Notes

  • Started with a vote between this talk and a programming language one. This talk (barely) won

“Agile”

  • Wish people would stop using word “agile”
  • “Agile” is now an industry
  • “Agile” co-opted
  • Was supposed to be on what values need to apply, not the practices
  • Can’t sell or package values
  • Can’t be agile if handed a process

“Agile is Dead”

  • Agile is dead. Agile with a capital A is what you pay for. Lowercase agile is the original set of values.
  • Devs are unhappy with Agile – too many meetings and processsed
  • Read great quotes from Death of Agile quotes all of which value agile principles

Agile noun vs adjective

  • Agile has become a proper noun; something people can package/sell/make you follow.
  • agile should not be a noun. A noun is something you can point to
  • agile should be used as an adjective
  • It was made a noun to sell it; you can buy a pound of green
  • Agile is lost to us; how do we reclaim it?

History

  • How do we reclaim it?
  • 1995 – 31% failed, 53% partial success (overbudget or late or didn’t deliver all functionality)
  • 2020 – 11% failed, 47% partial success
  • Can’t go back
  • Too few people started programming when everything was specified up front and the problems to remember why it was bad.
  • Requirements change

agility

  • Take back control
  • Ignore the branding
  • Make it work for us individually and as a team
  • Create a living, evolving local set of values and practices
  • There are things you can’t do that would like to do. That’s live. Still much you can do at a local/team level
  • Can’t change everything – business promises things, have the initiate carefully and measured
  • Better off than are today by improving locally

First page of manifesto from snowbird:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Value

  • Values are an internal filter through which you make decisions
  • Make decisions based on the four values in the manifesto
  • It’s difficult to do this. But the code is hard to write too

Skills need

  • Empathy – see things as someone else sees. Cognitive (thinking) and affective (feeling). Also need empathy for things so understand how will react/stress under.
  • Storytelling – everything we do is an abstraction; using stories/metaphors allow people to understand.
  • Feedback – Classic feedback loop. input -> process -> result -> compare to expectations -> input. In software, we apply the feedback to the process (or expectations) instead like in unit testing. Could also be the process used to create the code in the first place. Aka error when coding, bad assumptions, or systemic error. The third is most valuable, but done the least.
  • Change driven – spent most time changing things vs building new things. Development is a nested set of change cycles. Software is the most malleable building component. Think or work as a series of steps instead of an outcome.
  • Value focused – Goal is help people and add value. Working software is a means to an end. Earlier delivery is more valuable so cadence is a trade off against accumulated value.
  • Courage – being an agent of change means making mistakes. Don’t hide behind the process or make excuses. It has to be ok to make mistakes. If we are taking control or handling something, we are accepting responsibility for it. If we communciate effectively and honestly and are ignored, they are responsible. Don’t let an imposed constraint be a stressful responsibility unless you’ve accepted it.

What can I do

  • no-one knows
  • nobody can know what you individually should do
  • except possibly you
  • you are the only person who understands the constraints living under and your personal values.
  • What to do – Find out where you are now, take a small step towards your goal, adjust your understanding based on what you learned, repeat. That’s agility!
  • How to do it – When faced with 2+ choices that deliver roughly the same value, take the path that makes future changes easier

Example

  • Unproductive meetings – Goal is to feel more productive.
  • Non agile way is to say nobody can speak for more than 3 minutes and pass around the teddy bear.
  • Agile way – start with why have them – know what’s going on, identify frustration, planning, serendipitous discovery, etc. Identity downtime. In classic Scrum 17% of time is in meetings.
  • Small step #1: stop having meetings. Then adjust based on what happened. Will world end if abandon meetings for 2 weeks? Will company collapse? [seems like a big step]
  • Found delivery went up but two cases of duplicated effort and lost too much communication.
  • Small step #2: senior dev spends an hour a day chatting with individuals. Find common problems, patterns, and opportunities. Helps with small problems and brings people togehter for larger one. Found unnecessary activity and local expert
  • Small step #3: change to 45 minutes a day
  • Be prepared that will change over time
  • Called “Developer without a portfolio”. 6/45 independently evolved to doing this. Most had a full time facilitator/ambassador. None wanted to go back.

Another example:

  • Problem: when we refactor, we spend too much time fixing up the existing tests
  • Side story: Tests were brittle and a lot of failures on new machine. Deleted all internal tests and reintroduced as needed.
  • Why have tests: validate functionality, protected against regressions, inform design
  • Cost: Time to fix when fail
  • Small step #1: disabled on API tests after code written. Rely on caller to find issues. Make sure tracking error rate metrics before and after change
  • Months later no observable change and refactorings faster. Found unintended coupling
  • Small step #2: addd test to detect coupling and investigate cause

Closing

  • agility – bring back the fun

Q&A

  • How was it rewriting pragmatic programmer 20th edition? Threw out or rewrote a lot 30% of tips. Changes references in many others or described better. Ideas themselves didn’t change. Common sense. Things people know. Seeing it written down validates. Gave names to concepts that didn’t have.
  • Example of storytelling of what we do? Use point of view of customer using product
  • How change more? Get others to make small changes too

My take

Awesome keynote. It was so nice to meet Dave in person. It was great seeing his perspective. The material is helpful in impacting positive change. The info and examples are great. Missed a little of the end of Q&A to setup for my session

[2021 kcdc] black holes and revelations

Posted on by
Reply

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Sarah Harper

Twitter @sarita1119

————————-

Why work gets stuck

  • Work moves through the system until it gets stuck in a phase
  • We like to think of things as a process problem. However, often a behavioral issue (not like major HR leve problems)
  • Reasons: someone out sick, not enough people know how to do something, blame testing
  • Agile black holes!
  • Detrimenta to process and team morale
  • Not obvious what problem is
  • examples: deployment, business requirements, code review, qa
  • Biggest black hole is the backlog

Back hole theory

  • Any work status which acts as a “holding pen” for work items will eventuallly turn into a black hole
  • Once enough are blocked for same reason, all future items will becme blocked
  • It becomes acceptable for things to get blocked there
  • No work appears to be done to outside observer – unclear who working on or what it is up to

Symptoms

  • Queue busts – something wrong and swarm around it. Teams decides to focus on something like a customer service queue.
  • Eceeed WIP limits
  • Blocked column
  • Too much in “done” or “ready” columns
  • Long staging cycle time

Learned Helplessness

  • Exercise: everyone got a piece of paper with three anagrams and people raised their hand as solved
  • One one side, first two not soleable. One other side, first two easy. Then same third one.
  • Taught first group learned helplessness.
  • Trained to give up.
  • I tried X times to change this

Locus of control

  • Exercise: how much control do you have over weather, food you eat, comute, home, projects at wor, team member participation. (Scale of none to all)
  • Think about what under control
  • Don’t blame others for things can control
  • Be alert when someone says can’t/imposssible

Self handicapping

  • Don’t try so can’t fail
  • Fear of looking bad
  • ”give to X because X can do fastest” – setting team up for failure if that person can’t do it.
  • That person becomes busy and a black hole
  • ”You miss 100% o the shots you don’t take”

Somebody else’s problem and the bystander effect

  • Brain edits it out because someone ese’s problem
  • Everyone ignores
  • May or may not actually be someone else’s responsibity
  • Bystander effect – assume someone else will take charge

How spot black holes

  • If have to scroll in a kanan board, have a black hole
  • Not obvious

Visual principles

  • Excercise: think about your kanban board For each of these principles
  • Figure ground – foreground vs background. What see vs ignore. Showed optical illusion of face/vase. Usually digital boards have a white background so white cards disappear into background. Can make a different color to stand out. Also, if something has a date contraint or a high priority, add contrast.
  • Common region – when obects located in same region, we perceive them as being grouped together. If everything looks the same, can’t tell. Change blocked cards to a different color
  • Similarity – thinks that look the same are assumed to be the same.
  • Proximity – things close together appear to be more related than things spaced farther apart. This is more of an effect than similiarity
  • Continuity – Elements on a ine are considered more related. Lines follow the smoothest path.
  • Focal point – watever stands out visually will attract and hold our attention
  • Closure – we try to find recognizable patterns
  • Just noticeabe difference – hard to see Jira dots for how long in state
  • Idea: have blocked work in a different color, in a lane on top. So you can see status blocked in.
  • Avoid too much color

Game: https://getkanban.com/pages/free-version

Escaping back holes

  • Have team talk about problem
  • Visualize future state and take action
  • Use a physical board or customize digital board as much as can
  • FInd an influencer on team that will give good feedback and help team accept idea
  • Queue bust (swarm around problem)
  • Root cause everything

My take

I learned a lot at this session. I like how it was different than a lot of agile talks. I have a bunch of things to take back

Responding to a co-located/fully remote/hybrid article

Posted on by
Reply

I read Should Your Organization Be Co-Located, Fully Remote, or Hybrid from Scrum Inc. It’s nice to see the agile community starting to accept that co-location isn’t necessary to be an agile team. (I’ve been on a team for many years with people in multiple locations and it never stopped us from doing Scrum. We even figured out how to make in person agile games remote. A few takeaways/responding

Feedback

I really like this quote

Uncollected feedback is perishable; the longer you wait the less reliable it is

Many years ago (even before doing Scrum or remote.), I noticed that people had trouble recollecting what they wanted to contribute to the retrospective. They were quiet at meetings and didn’t remember problems not fresh on the mind.

I solved this by putting a shoebox and post its in a common location. This let the team put in their thoughts right as they happened.We had someone organize the post its by topic and used the retrospective time to discuss them.

Over time, that shoebox became electronic. But the benefits still stand. Real time opportunities to record those thoughts. I really like the perishable quote and am sharing it with my current team at our next retrospective!

Purpose of an office

The article lists the following benefits of an office. It was interesting reflect on how much of this applies to me and my troubles over the last 15 months. The table shows my thoughts on them both for work and the high school robotics team I mentor

Item from articleWorkRobotics
Collaboration, communication, and the sense of belonging that comes with colocationI’m not sure. It’s definitely good seeing people, but my team has been distributed for years. So a lot of my connections were with people not on my team anyway.Definitely. The kids noticed how much they feel not being able to hang out, have team dinners, bond over dodgeball, etc
A place to work away from the distractions of homeYes! This is one of the problems I’m having. (I put not having a good physical work space in this area. A subpar work environment is certainly distracting.)Some of the students share rooms or have distractions on calls.
Creation of physical products and use of specialized tools n/a – our tools are computersDefinitely. Not having access to the lab, tools, robot greatly limits what can be done.
Space for gatherings and training While I don’t need to see my teammates every day/week, we do all meet in person on occasion. In person meetings allow for more flexibility and cross training
A need to directly interact with customersn/an/a
A place to focusAnother one for me. I only have so much energy to focus at home. It’s less than 8 hours worth which isn’t even enough for a day let alone fun things after work. I also notice, I can’t carry as many thoughts in my head at home.Not sure.
The status and stability a physical location conveysn/an/a

Sustainablility

Another quote I found interesting:

Working more hours to get less done is not a recipe for success. 

For most of the weeks of the pandemic, I refused to work more hours. (I made an exception for the a month and there was a high cost. I’m still recovering to get myself to the point I was at the week before I made that exception.) I got less done but it wasn’t from more hours.

Most of my colleagues get the same or more done at home. They should be able to to telecommute forever! I am not one of those people. At the office, I have a desk so I can see more stuff at once. I have two monitors so I can work faster. I can hold more thoughts in my head

And also

There will be times when after-hours work will be needed. These need to be the exception – not the rule.  

I agree with this. And I made that monthlong exception intentionally. Also my employer passed the “test” of it being important. I worked one weekend day in exchange for a comp day. So at least it was my employer’s time too, not just mine.

I hear a lot of people say “since I’m not commuting, I can work more.” I strongly disagree with this. I used my commute time productively. I read the news in the morning and a computer book on the way home. (My computer book reading is also down because my at home energy isn’t available when I have time to read now.) Commuting time belongs to me, not my employer. It being gone isn’t a reason to work more hours.

Hybrid workspace ideas

The article also lists some ideas for hybrid work. My thoughts on those

IdeaResponse
Have designated team days for in-person workWe did that when we were a colocated team with telecommuters. (Monday was the day nobody could telecommute.) I consider this a crutch that we long moved past. Luckily we became a multi-city/time zone team after I no longer needed that crutch!
Institute policies to fight ‘Zoom Fatigue’ and burnoutThe article suggests holding 10 minute breaks between meetings. I’ve had meetings 9:05-9:55 for as long as I can remember. So meetings i control do come with those breaks.
Always hold team events in virtual conference spaceThis one we didn’t quite do. We did have people at the same site connect from the same room rather than everyone being at their desk. But everyone did contribute equally. It wasn’t most people in one room and a handful alone at home.
Publish all meeting notes in a visible space which can be accessed remotelyEverything is electronic. While we do publish notes, we aren’t an async team though.
Only use virtual whiteboardsDefinitely! The only time we used physical whiteboards was for pairing when the two people involved happened to be in the same location.