Many software development teams, especially those creating or supporting a shared platform or infrastructure, find themselves overwhelmed by ad-hoc work requests. A frequent response to this situation is to move from an iterative, incremental practice to Kanban or some other flow-based model. In many situations, this is the exact opposite of what should happen. When a team finds itself foundering under the weight of system support or ad-hoc work requests, it may be time to
I’ve had some great opportunities working with teams applying lean and agile techniques to domains beyond software development. Along with other areas, I’m having lots of conversations around applying Scrum in HR teams. This is fairly unique because the core usage model for Scrum is to apply it when the work is fairly unknown and complex, and the team is working together to create a shared product. Many knowledge worker teams simply aren’t like this.
Several teams I’ve worked with wonder why it is important to finish work within the Sprint timebox. “This is an artificial container for my work,” they explain. “Why can’t our work just take the time it takes? Why must it be get all the way done in one Sprint?” In my experience, these frustrated teams are likely looking to move away from poorly implemented Scrum toward what will be disastrously implemented Kanban and just-in-time work
In the 80’s there was a commercial where two people – one carrying a chocolate bar, the other a jar of peanut butter – run into each other. One says ‘Hey! You got chocolate in my peanut butter’; the other says ‘Hey! You got peanut butter on my chocolate’. Today it seems that User Experience Professionals and Agile Development teams are those two people, yet no one has quite figured out how to make
I’ve been learning about functional programming for quite some time now, trying to wrap my head around the various concepts that this paradigm has to offer. One of the languages that spiked my interest besides Clojure is F#. The reason for this is quite obvious. As a software developer who uses the .NET framework on a daily basis, I regularly run into the limitations of C#. Embracing a powerful functional language that targets the CLR
Scrum calls for a Sprint Review, which is essentially a demo with stakeholders providing feedback used to guide the next iteration of work being planned. There many techniques used for Sprint Reviews and here I’ll explain one that might help if you find yourself in a large organization with many Sprint Teams vying for the opportunity to show their work. Simply put: Host an internal blog dedicated to posting Sprint Reviews videos from teams around
A REST API (what I like to call a developer UI) uses HTTP itself to signal return codes. While this is very useful and logical, it creates a situation that can almost feel like a leaky abstraction. Was the 404 error code generated from the REST API failing to find a specific resource, or was it thrown by the webserver because the endpoint isn’t present? Subcutaneous testing  can help identify when a thinly-wrapped API