The Zeigarnik effect relates to task-specific tension, which improves cognitive accessibility of context to the task. The tension is relieved at the completion of the task, but it persists if it is interrupted. Through continuous tension, information can be more easily remembered long-term. This is useful to know if one's desire is to remember information for an upcoming test, but less useful if your intention is deep, focused work.
The Ovsiankina effect is the related, insidious tendency to be distracted by unfinished tasks over the task at hand. When a task is interruptive, the brain will fixate on it, wanting to complete it. When attempting to focus elsewhere, the brain will continue to project intrusive thoughts related to the prior, uncompleted, task. This cognitive dissonance can be very frustrating, reducing our ability to focus effectively.
This has several implications on motivation when working with a team. The first is that it is critical to decompose large tasks into smaller pieces, so smaller pieces can be completed without interruption. Completion of the whole objective – no matter how small – enables the brain to completely unload the details of the task, allowing us to effectively change focus to whatever needs our attention next and dive in without any excess cognitive load. Consider adopting a "definition of done" that enables your team to clearly know when they can unload from a task.
The second implication is that we're twice as likely to remember work we haven't finished over work have finished. Therefore, there's a natural negative bias that can creep in, giving the impression that we aren't accomplishing our objectives at all, or not enough relative to our tasks on hold. As leads, it's important to recall and celebrate the successes that are happening across the team, and how they are contributing to team objectives.
My preferred place for this is in our team retrospectives, which happen at a regular cadence, but don't overlap with our weekly sprints. If I celebrate wins in a weekly meeting, I've found it can become a little expected, and forced, even, to come up with something. But by presenting it during a retrospective, where everyone is looking for some ideas to contribute from the past few weeks, accomplishments will be recognized from angles I might not even know about!
The third implication on motivation is to address the most significant technical debt has has been accruing on the sidelines. Once a quarter, clear it out. Either dedicate some time to wrap up the top items, or throw it out completely. Having a backlog of items you are are not likely to address will only make it harder for your team to unload from previous tasks.
And that's that. Keep it simple, keep the user stories small, get to the definition of done, and avoid the Zeigarnik effect!
]]>Interesting new presentation on "dark agile". As someone who has seen truly agile teams thrive, yet also worked in "agile" environments that were offensively infuriating, I'm feeling vindicated to have this new label that seems so well-fitting for so many companies who claim to
]]>Interesting new presentation on "dark agile". As someone who has seen truly agile teams thrive, yet also worked in "agile" environments that were offensively infuriating, I'm feeling vindicated to have this new label that seems so well-fitting for so many companies who claim to be agile but are nothing of the sort.
That said, there's a few things about this talk that I take immediate issue with, with the first being Allen's assertion that Jeff Sutherland's take on Scrum is not agile, and that his book Doing twice the work in half the time "flies in the face of what Agile is about". It's not always so black and white.
Yes, Scruminc is a for-profit company making money off of Agile, but it's a far cry from SAFe and the "agile industrial complex", which is real and harmful.
My read on this is that Allen is a little more idealistic than Jeff in his approach to behaviour. Jeff's book is designed to sell. It's business-oriented, it has a catchy title and it's marketed to companies that are looking to profit off of more effective software delivery.
But it's unfair to present this book as harmful. Jeff specifically states that his book establishes what Scrum is (not what Agile is, as agile is "individuals and interactions over processes and tools") and that the ideal intention is for a team to onboard into Scrum and use it as a launching point for agile. Like training wheels. Personally, I've found this approach practical and even subversive in its effectiveness.
]]>Lots of questions on this lately as we examine how our product teams could scale.
Requirements are the input to your engineering function. It's what your client wants. They are idealized descriptions of what the client thinks they want the software to do. They're generated ahead
]]>Lots of questions on this lately as we examine how our product teams could scale.
Requirements are the input to your engineering function. It's what your client wants. They are idealized descriptions of what the client thinks they want the software to do. They're generated ahead of time, often as the output of brainstorming, or in the best case, prototyping.
The responsible software developer will use this as a starting point, and engage in a requirements gathering or discovery phase. The client likely won't know to include every useful piece of information that enables engineering to make the best decisions, so it's on engineering to probe a bit deeper.
This might be as simple as spending time with the client prioritizing the requirements and capturing the most immediate use cases and most prominent concerns. Discussions will also likely touch on quality attibutes such as security, performance, responsiveness.
Acceptance Criteria are then the agreed-upon measures of what will be delivered. They are drafted by engineering take into consideration the current realities at the point of delivery. The client doesn't know about the state of your software stack when they are coming up with how they want the product to work. They likely care more about getting the right thing out quickly and cheaply then the exact thing described in the original requirements.
A technical surplus might make certain approaches easy. In the same manner, accrued technical debt could make other approaches difficult, to the point where it's desirable to put it off until costs can be significantly lowered. Previous architectural choices could warrant a change to user interface behaviours.
Acceptance Criteria enable alignment on outcomes and managed expectations. It's not only what will be delivered, but what will be delivered effectively, with reduced risk, and on a smaller timeline.
]]>Michael Lopp's favourite part of the phone screen is taking questions. The interviewee gets to show off their research skills and ask probing, insightful questions, and Michael gets to answer them.
I'm not a fan of lazy questions. I can think of no better way to
]]>Michael Lopp's favourite part of the phone screen is taking questions. The interviewee gets to show off their research skills and ask probing, insightful questions, and Michael gets to answer them.
I'm not a fan of lazy questions. I can think of no better way to move yourself down the list of qualified applicants if your questions are the kind that can be answered by spending a few moments on LinkedIn, Crunchbase, or a personal bio. I might actually prefer no questions over lazy questions!
The types of questions I prefer are those that demonstrate follow up on a previously published blog post or comment. Questions about the inner workings of the organization, upcoming products, technical challenges, interpersonal or organizational challenges, or the future of the company.
Here's a list of generic questions I might ask in a screener interview. These questions are likely best-suited for engineering and engineering manager roles.
Tweet me if I missed any good ones! @codydjango
]]>A few months back Martin Folwer put out a transcript of his 2018 keynote at Agile Australia. As usual, there were many snippets that jumped out at me, and many that hit close to home. Many of the "agile transformation" environments I've worked in over the
]]>A few months back Martin Folwer put out a transcript of his 2018 keynote at Agile Australia. As usual, there were many snippets that jumped out at me, and many that hit close to home. Many of the "agile transformation" environments I've worked in over the past decade experienced dysfunction, stemming from a over prescription of process and lack of technical expertise.
Martin Fowler speaks to these complications, and aptly provides a nice little "Faux-Agile" label that I'll be sure to use from now on.
"Our first problem is dealing with the Agile Industrial Complex"
I've lost count of the amount of times someone would exclaim out loud, exasperated, something to the effect of "Agile just isn't for me", "Agile just won't work for our team", or "why are we adopting a new process? Can't we just get our work done?"
I'm an agile enthusiast. I advocate adopting Scrum or Kanban, specifically for new teams in the "forming" stage, or existing teams with poor execution. But I also advocate for peeling away processes if they are no longer necessary, if the team has grown beyond them.
"The Agile Industrial Complex imposing methods on people is an absolute travesty"
Engineers are smart people. Designers are smart people. Give your product teams the tools to be able to do their best work.
"A team should not only choose its process, but continue to evolve it"
If engineers aren't active in Standup, it's because they're active outside of it. They have their own channel of coordinating, and they are protecting them from outside hijacking. There is no one-best-way solution for a high-functioning team. It depends on the particular individuals and interactions.
"The second problem is the lack of recognition of the importance of technical excellence."
Vindicating to hear something so obvious: that technical excellence is a required precondition to high-execution agile teams. The belief that hiring a group of people with a variety of limited experience, placing them on a project with a scrummaster, and expecting that they will be able to estimate, execute, and reflect with any degree of precision -- even months later -- is simple naivity.
Engineering is hard and technical. Product ownership is hard and technical. UX is hard and technical. Expertise is crucial!
Yet in agile transformation projects, while there maybe be representatives of the business, who is responsible for assessing the technical expertise required for agile teams to thrive? If the head of engineering is not focused on ensuring the right people are in the right roles, who is?
"Oh, we need to create a whole new world for ourselves. The software craftsmanship movement where we can go away, get away from all of these business experts and project managers and business analysts, and just talk about our technical stuff."
Agile was created by technical people wanting to be more productive in risky situations. So why are technical people effectively pushed out from agile discussion in 2018?
Project managers and product owners who do not share the correct understanding of refactoring should have no place on an agile team. Refactoring, as a housekeeping behaviour, is crucial for high-functioning teams.
"Refactoring is lots of small changes, none of which change the observable part of the software"
But even when refactoring is well-understood, what seems to be even less understood is that refactoring is hard. Effective teams require experienced software engineers writing code, reviewing code, and caring for the code. Software development isn't just a day job -- It's a vocation!
Lastly, Fowler speaks to the imperative to organize around products, and not projects. This is perhaps quite obvious to anyone at a typical startup, but still quite a unique concept to many traditional enterprise organizations.
Hire good people. Give them clear markers and direction. Provide them with tools, books, and support. Let them figure it out.
]]>Three weeks ago I started at a new company: I've taken on the role of lead software engineer at a Vancouver startup focused on bringing to market virtual reality business solutions. Our first product bets target the AEC industry (architecture, engineering and construction), specifically architecture firms engaged in
]]>Three weeks ago I started at a new company: I've taken on the role of lead software engineer at a Vancouver startup focused on bringing to market virtual reality business solutions. Our first product bets target the AEC industry (architecture, engineering and construction), specifically architecture firms engaged in early-phase architecturural work.
A few months back the team started a transition from prototyping to product, with the goal of bringing their first product to market by the end of the year. I've been brought on to help with that effort.
The team is very bright and capable, but new to concepts like maintainability, continous delivery, lean development, story mapping, and agile iterations.
The tech stack currently is spread between heroku client/server web applications, unity and firebase. I've spent the first few weeks assessing the existing codebases and introducing minimum viable style guides and linters, and containerization for some of the more complex applications.
]]>Saw this one on amazon when perusing books on agile and team management, took a chance on the kindle version. Surprisingly relevant -- I seem to be on a very similar track as Johnathan Nightingale, although maybe five or ten years behind him. A lot of his startup experience resonated
]]>Saw this one on amazon when perusing books on agile and team management, took a chance on the kindle version. Surprisingly relevant -- I seem to be on a very similar track as Johnathan Nightingale, although maybe five or ten years behind him. A lot of his startup experience resonated deeply with me, especially the consequences of naive product management.
If you've spent time in the trenches; if you've developed contempt; if you're convinced that the problem is not the tech, but perhaps something else... You're not alone. This was a very cathartic read.
And a quick read, too. It took maybe three or four sessions, and because it was based on blog posts it's very digestable in small portions. This book also pointed me in the direction of many other influential articles and books that I hadn't yet come across, which I appreciated.
]]>I have a renewed interest in Agile. I suppose the last few years of "corporate" software projects have left a.. taste in my mouth. Agile at startups seemed much easier to implement, since the teams were smaller and had already bought in to the process. We shared the
]]>I have a renewed interest in Agile. I suppose the last few years of "corporate" software projects have left a.. taste in my mouth. Agile at startups seemed much easier to implement, since the teams were smaller and had already bought in to the process. We shared the goal of delivering features. At the agency and enterprise level there are just so many more actors to consider: stakeholders, external teams, embedded clients, multiple review processes... It's much harder to achieve organizational alignment towards an agile process, even if everyone signs off "in theory".
I now identify the combination of a general lack of experience in agile and a lack of clear governance in product development the largest risk I've faced on the largest projects of my career. I've spent much time over the last five years researching and practicing maintainable code and architecture to allow a codebase to be as easy to be productive in and to enable the types of change requests and pivots that come from a truly agile environment, but it's now obvious to me that the largest bottleneck is not in architecture or even development. The bottleneck is in agile and delivery.
A few weeks back I was looking for Agile books written specifically for organizations -- how to bring about an orientation to a successful agile process at an organizational level. One that kept coming up was "The Phoenix Project" (in addition to "Mindset", which is not a book on Agile, but on enabling a mindset of change and growth).
The Phoenix Project is a novel, and it barely mentions "agile" by name. I enjoyed it much more than expected, and have already recommended it to many coworkers: developers and managers especially.
The Phoenix project is really a book about a failing organization trending towards agile adoption and a continuous delivery pipeline, but it really shines in the clarity of it's vision. It's an inspiring read with contributors who really know what they are talking about (Jez Humble is a leading figure in continuous delivery systems). The introduction of DevOps as an integral evolution of IT seems profound yet also possible and beneficial to apply at even for smaller teams. I think this is because the axioms and objectives are so well defined.
The "Three Ways" described in the Phoenix Project are already repeated often in enterprise and agency settings, and this is unfortunate. They are described without their context and therefore feel weak and cheap, just another example of a buzzword in tech.
Essentially the "Three ways" is a way of realigning business goals towards "systems thinking". Once a single business requirement can be achived through the business IT operations infrastructure, it's about developing a tech and culture that allow simple ways to identify bottlenecks and iterate on them. Essentially lean iterations on internal IT and Dev processes, in a similar way that Lean taught us to take an iterative, MVP approach to product. I'd like to write a bit more on the Three ways, maybe next week.
Gotta run to the a Russian opera!
]]>I just finished reading Carol S. Dweck's "mindset", and I wish I could have read it years ago! Does a wonderful job providing a mental model for wetware refactoring. I'm always looking for tricks to curb my reptile brain, and this book was full
]]>I just finished reading Carol S. Dweck's "mindset", and I wish I could have read it years ago! Does a wonderful job providing a mental model for wetware refactoring. I'm always looking for tricks to curb my reptile brain, and this book was full of them. Also, it was written in a very readable style and had many interesting anecdotes from a variety of sources including education, athletics, relationships, and business.
I specifically picked up this book because it was very highly recommended on the "Agile" subreddit, and I was not dissapointed!
]]>A few weeks back I participated in a four-day Agile training provided by the POWERSHiFTER client I've been working with for the past year and half.
The client started a transition to Agile about 3 years ago, but corporate environments are slow to change. This particular client did
]]>A few weeks back I participated in a four-day Agile training provided by the POWERSHiFTER client I've been working with for the past year and half.
The client started a transition to Agile about 3 years ago, but corporate environments are slow to change. This particular client did not have much experience in what a successful Agile development workflow looks like, with varying experience and expectation across the whole department. So in my mind, this training had long been overdue.
The session I participated in was more oriented towards the technical staff, especially developers and QA. In fact, I'd say it wasn't really "Agile"-specific training at all -- it was training in how to write expressive and maintainable code -- the type of code necessary for Agile to work effectively.
The training was provided by the Toronto-based LeanIntuit. Declan Whelan was flown out to Vancouver, spending two weeks with two separate development teams.
The first day was on Acceptance-test driven development, which presented a vision of how Agile teams go from incoming requirements to defined user stories with acceptance criteria, to automated tests (using cucumber), to realized features in production. The takeaway was that a whole Agile team can work together effectively to systematically introduce new slices of functionality. Not especially relevant to our exact day-to-day, but a good presentation of how Agile could work, and does work, in optimal environments.
The next few days were largely around TDD and clean-coding techniques. It was largely 101 stuff, but a welcome refresher for myself, and a much needed introduction for many of the attendees.
It's not that the developers of this client are particularly bad developers -- just that they have not been able to benefit from experience. Declan was quick to point out that he sees this dynamic at nearly all of the companies he provides training and coaching to:
Developers who have never read Clean Code or Domain-driven Design, developers who have never been introduced to concepts like SOLID Principles, Simple design or Extreme Programming. Javascript developers unfamiliar with functional programming and backend developers who believe TDD is a waste of time.
It was neat to see the eyes light up of individuals when things would just "click" for them. After three days of practical exercises and discussion, many people seemed much more open to ideas that Declan presented with care, without much force.
One particular technique that stood out for me was the "Golden Master", used in refactoring legacy code -- especially legacy code with minimal/non-existent/failing unit tests. Oh, I can think of multiple occasions where I wish I had known about this one. In a nutshell, all original output is dumped to files, and as you refactor you comparing diffs between the new output and the original (the "golden" master). If the output differs, then you've messed up or introduced a bug.
]]>