1. Problem Context


    There are multiple sources for requests to do work which leads to unclear priority OR a de facto prioritisation approach based on who shouted loudest most recently.

    Most things seem to take too long to complete which leads to more direct requests to individuals to expedite work.

    People doing the work are frustrated by the inability to focus on anything as interruptions are constant.

    Solution


    Move all requests to a single input queue with a common prioritisation method - no requests are processed unless they come from this queue.

    The prioritisation method may or may not allow explicit expediting but it will be a common policy, not a backdoor request.

    Expected Consequences

    • People making requests who were used to jumping the queue may feel disappointed
    • Average lead time will drop and become more predictable
    • People doing the work will feel more focus and satisfaction
    Posted by
    Labels: agile one point lesson
    0

    Add a comment

  2. Does Agile encourage developers not to think about the future?

    You Ain't Gonna Need It

    The argument against Premature Generalisation is that a lot of bloated software designs come from well-intentioned software designers attempting to prepare for anticipated needs, just in case.  Instead, you remind yourself that You Ain't Gonna Need It, that the carrying cost of more complex code will be greater than any anticipated future cost of change AND that a simpler design is always easier to modify to address an unanticipated design need than a complex one.

    In other words, don't anticipate any specific future but be ready for any future.  See Kent Beck's Rules of Simple Design.

    I will accept that this doesn't really work without the discipline of simple design.  Hence, issues with Flaccid Scrum.

    What's the simplest thing that could possibly work?

    There was a slogan in Extreme Programming called "Do the simplest thing that could possibly work."

    It came from a pair programming episode with Ward Cunningham and Kent Beck:
    So when I asked, "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. Our problem is we've got nothing."
    Asking the question "What's the simplest thing that could possibly work?" is about focus; it's about trying to focus on the essence of a problem rather than try to solve every problem at the same time; it's about dealing with the blank page problem in programming.

    Does Agile encourage developers not to think about the future?

    So it seems that the Agile community is encouraging developers not to think about the future.  Well, not exactly.

    There's nothing wrong with thinking about the future per se.  The problem is to allow thinking about that future to distract from what you need to deal with right now.  The problem is acting upon that future prematurely.

    The Agile approach is to not anticipate any specific future but be ready for any future by keeping the design simple.
    Posted by
    Labels: agile premature generalisation simplicity yagni
    0

    Add a comment

  3. Is Agile just throwing stuff together as quickly as possible?

    The older version of this was some variant of "Extreme Programming is just hacking" or "Extreme Programming is just cowboy coding".

    In essence, the suggestion is that Agile is equivalent to "Code and Fix" or "Cowboy Coding".

    Kent Beck describes the heartbeat of an Extreme Programming episode in response to the "Why is XP not just hacking?" question.  Paraphrasing for length...
    1. Pair writes next automated test case to force design decisions for new logic independent of implementation.
    2. Run test case to verify failure or explore unexpected success.
    3. Refactor existing code to enable a clean and simple implementation. Also known as "situated design".
    4. Make the test case work.
    5. Refactor new code in response to new opportunities for simplification.
    Does this reasonably sound equivalent to "throw stuff together as quickly as possible"?

    Granted, not every Agile team has this kind of technical discipline.  Hence, so-called Flaccid Scrum and the advocacy of Two-Star Agile fluency.

    Also, granted, that sometimes one should throw stuff together quickly when the purpose of the exercise is to test an experimental concept.  For example, "spiking a solution" or an initial MVP.
    Posted by
    Labels: agile misconceptions
    0

    Add a comment

  4. 1. Read

    Read one or more of the following:
    (FREE) Explore Don Well's site: Extreme Programming: A Gentle Introduction.

    (FREE) Read the Scrum Guide.

    2. Participate in the community

    Join a local user group.  Meetup.com currently dominates.  I'd suggest also finding or setting up a local Lean Coffee.

    Follow Agile people on Twitter.  My handle is @jchyip.  There's an old 2012 list of "The Top 20 Most Influential Agile People".  Probably a reasonable group of people to start with.

    Subscribe to Agile blogs.  There's an old 2011 list of "The Top 200 Agile Blogs".  Probably a reasonable place to start.

    3. Learn and practice the craft

    1. Learn about User Stories and User Story Mapping
    2. Learn Test Driven Development (TDD)
    3. Practice TDD and Pair  Programming
      • Practice using Code Katas.  Alternatively, look for similar language-specific exercises for your particular programming language.  For example, Ruby Quiz.
      • Find or setup a Coding Dojo.  This seems to have become more rare so instead...
      • Join or host a CodeRetreat.
    4. Learn about testing in the Agile context
    5. Learn about Continuous Integration and Continuous Delivery
    6. Write about what you are learning

    3. Learn the big picture

    1. Read about the Agile Fluency Model
    2. Read Patterns of Enterprise Application Architecture by Martin Fowler
    3. Explore Lean Software Development
    4. Explore Kanban for software development
    5. Explore Lean Startup
    6. Watch Spotify Engineering Culture videos (Part 1) (Part 2)
    7. Attend conferences.  I recommend smaller, local, not vendor-focused conferences rather than the massive ones.  Open Space conferences tend to be good if you get the right crowd.  YOW! / GOTO / QCon tend to be good.  Lean Kanban conferences tends to be good.

    4. Explore the less known

    1. Read Crystal Clear by Alistair Cockburn
    2. Read Agile Software Development by Alistair Cockburn
    3. Read Lean Product and Process Development by Allen C. Ward
    4. Read The Principles of Product Development Flow by Donald G. Reinertsen
    Posted by
    Labels: agile
    0

    Add a comment

  5. In Lean Manufacturing there is a role called mizusumashi or "water spider" which is nominally someone who fetches material for operators on a line.  Jon Miller has a good blog post clarifying misconceptions about this:
    "The Water Spider position is often confused with a simple material handler or an entry level “go fetch” person. Far from it, the Water Spider needs to be thoroughly familiar with the materials, tools and methods of the process they are supporting."
    In other words, the Water Spider cannot be effective in supporting a process, unless s/he is thoroughly familiar with it.  Unlike water striders that only skim the surface, we want water spiders that can go deep into a process if necessary

    John Shook wrote about his annoyance with people downplaying focus on working on the work in order to focus on changing culture (aka "ways of thinking"):
    "You may be able to create wealth through a variety of business models or ways of thinking. But if you want to create real value, and jobs that value people, you must think hard about how your people are working every day. That’s because the essence of lean thinking is about the WORK. Lean means working on the work: the value-creating work that occurs on the frontlines of your enterprise."
    So about Agile Coaches...

    I see a similar problem with a potential over-emphasis on "culture" and "management behaviour" independent of insight on the actual work that needs to be done.  That is, water strider Agile coaches.

    I submit that an effective Agile coach will be more like a water spider, able to go deep if necessary to support how people work.

    Of course, we must acknowledge the breadth and depth of knowledge involved in modern software development. It would take a lot of time of effort to become a water spider, but I'll still suggest that this is the right True North to set.
    Posted by
    Labels: agile coaching
    0

    Add a comment

  6. When I'm designing a build pipeline I'm primarily thinking about my impatience.

    How long am I willing to wait to get feedback?  Given how long I'm willing to wait, how confident am I about the quality of the feedback?

    I'm not so concerned with whether it's a "unit test", an "integration test", or whatever.  My criteria is not based on what type of automated check is in the build stage so much as how long the automated check takes.

    For example...



    Posted by
    Labels: build pipeline continuous integration
    0

    Add a comment

  7. As I posted earlier, "large, complex projects" in the enterprise tend to suffer from problems of alignment and overconfidence.

    I also posted typical "solutions" that don't work.

    Here are some solutions that help:

    Conquer, then divide

    "In XP, we don't divide and conquer. We conquer and divide. First we make something that works, then we bust that up and solve the little parts." 
    Kent Beck
    Setting aside market risk, the riskiest part of "large, complex projects" is whether all the various parts actually work correctly together (aka integration).

    The typical approach most "large, complex projects" is to build separate pieces with separate teams  that they then attempt to integrate.  This tends to cause multiple failures.


    A better approach is to start with an integrated solution, focusing on resolving the key integration points, using a single, highly skilled team, and ONLY when the critical integration issues are resolved, work out how to scale up to multiple teams.

    Have regular integration checkpoints

    Setting aside market risk, the riskiest part of "large, complex projects" is whether all the various parts actually work correctly together (aka integration).

    Problems associated with delaying integration is so common that it has its own name: "Integration Hell".

    The larger, the more complex, the project, the more difficult and expensive it is to have regular integration checkpoints.

    The larger, the more complex, the project, the more essential it is to have regular integration checkpoints.

    An integration checkpoint means choosing one or more end-to-end capabilities and synchronising all teams to deliver it at a common point in time.


    Milestones on "large, complex projects" that are not integration milestones are mostly theatre and a waste of time.

    Reduce accidental complexity

    "Accidental complexity relates to problems which engineers create and can fix... Essential complexity is caused by the problem to be solve..."
    No Silver Bullet, Wikipedia
    Large, complex projects, as the name suggests, are complex enough without adding additional, unnecessary complexity.

    Essential complexity reflects what is inherent to the problem to be solved.

    Accidental complexity reflects how we choose to solve the problem and is typically related to technology and organisational design choices.

    For example, that different customer segments may be using your product for different purposes is essential complexity.  That the product is split into N modules because you had N departments working on it is accidental complexity.  That your mobile product feels like a desktop product because you wanted to reuse your desktop UI is accidental complexity.

    Reducing accidental complexity comes down to choosing the right language, tools, design approach, and organisational structure for the problem at hand, not the problem you used to have.

    General themes of solutions that do work:

    • Addressing the critical aspects of uncertainty first
    • Addressing inherent uncertainty with regular feedback
    • Not making the situation even more complex with additional constraints
    Posted by
    Labels: enterprise large projects
    0

    Add a comment


  8. Posted by
    Labels: agile user stories
    0

    Add a comment

  9. Do we need this Agile malarky if all we need to do is get rid of all the "deadweight developers"?

     This question implies two other questions:
    1. Does an Agile approach improve less-skilled developers?
    2. Should we even bother improving less-skilled developers?

    Does an Agile approach improve less-skilled developers?

    Back in the day, there were questions about whether Extreme Programming (XP) was really only for highly skilled developers and less-skilled developers required more heavyweight approaches like the Rational Unified Process (RUP).

    Ralph Johnson (co-author of Design Patterns) described his experiences teaching software engineering at the University of Illinois where the students had both XP and RUP projects:
    "...they do not have the experience to design anything reasonable. If they try to follow RUP, the time spent designing is totally wasted. When they follow XP, they get test cases to run, producing horrible code at first. They don't make rapid progress, but they make progress. After a few months, they start to realize that their code is lousy and then reading the refactoring book helps them a lot. By the end of the year, they have working code and have become much better programmers. 
    So, my experience is that XP is especially good for novice programmers. It only asks them to do things of which they are capable. RUP can work if you have an expert who is trying to lead a group of novices, but if you don't have an expert then it will not work.
    This is not to say that RUP works better than XP if you have an expert leading a group of novices."
    In other words, XP is designed to use concrete feedback to develop skill.  I'm not as confident about other Agile methods and less-skilled developers.

    Okay, so let's say you accept that given less-skilled developers, an Agile, or more specifically, XP approach would help improve their skill.  There is still an open question of why you should bother improving their skill instead of just cutting the "deadweight developers" loose.

    Should we even bother improving less-skilled developers?

    There's a well-known response from W. Edwards Deming on how to deal with "deadwood employees":
    "Were they dead when you hired them? Or did you kill them?" (via Dealing with Deadwood)
    In other words, how much of the low performance of the developer is less a reflection of the individual and more a reflection of a broken surrounding system.

    Most "poor developers" I've met have had poor teachers and a poor supporting environment.  The question is, why should I design a system that only works with people who can compensate for being in an inferior system?  I would suggest that this is reflected in poor diversity and difficulty in finding people.

    When thinking about this topic, I tend to remember the story of NUMMI where the worst of the worst GM plant became the best in GM in about a year, with pretty much the same people, by adopting the "team way of working" (aka Toyota Production System).

    Workers who could reasonably be considered the worst kind of deadwood all of a sudden becoming examples of the best way of working.

    But we're not manufacturing cars.  Surely there is minimum level of sheer intellectual capability that not everyone has.

    I can accept that.  There are developers that perform better than others.  That's empirically true.

    Where I split ways is what the response is for developers who are not currently performing at the same level.  The best performer is the standard.  However, if you are willing to learn, we should be willing to teach.  If you are not willing to learn...

    There are also problematic consequences of believing in this idea of "deadweight" even for high performers.

    Believing too strongly that there are some developers that are deadweight and others that are not reinforces a fixed rather than growth mindset, which is a dangerous, performance undermining thing to reinforce, especially for high performers.

    Also, the mentality of abandoning people is incompatible with the reflex of empathy required to succeed in an Agile, and arguably any successful, product development environment.

    What I'd advocate instead

    1. Improve your selection criteria.  Some people do have greater skill and the right mindset to perform and improve much more quickly than others.  The right mindset is more important than greater skill BUT both is better and there is a minimum level of capability.
    2. Improve your human development approach.  I like the XP / Agile environment as a way to do this.
    3. Never reinforce the idea that anyone is deadweight.  The best is the standard, but if you are willing to learn, we are ready to teach.
    Posted by
    Labels: agile
    0

    Add a comment

  10. Do we need this Agile malarky if all that really matters is letting developer do what they think is right?

    This is a popular variant of "Agile is fundamentally just..." and is similar to "Agile is just for programmers", differing only in not wanting to identify with "Agile".

    Let's work through the reasoning.

    When building something effectively, how do you know what is right?

    In order to know what is right, you need to understand both the problem space (What problem are we trying to solve? What forces are in play? etc.) and the solution space (What options do we have? What trade-offs are in play? etc.).

    Nominally developers have the best understanding and insight into the solution space.  "Let the developers do what they think is right" implies that understanding the solution space magically means that you understand the problem space.  This doesn't make any logical sense.

    One-way communication from developers to product owners / managers is as illogical as one-way communication from product owners / managers to developers.

    Bringing perspectives together in order to gain understanding and insight of both problem and solution space does make logical sense.

    Doing what you think is right is ineffective if you have no justifiable reason for those beliefs.

    See also Lean Startup.
    Posted by
    Labels: agile
    0

    Add a comment

Blog Archive
Blog Archive
About Me
About Me
Loading
Dynamic Views theme. Powered by Blogger. Report Abuse.