As lean and agile development methods are becoming increasingly proven in many software development industries, the interest for large scale agile transitioning programs is booming.
An intuitive guide to efficiently track and manage projects in an agile way using GreenHopper for JIRA.
Agile is a set of values, principles, techniques and frameworks for the adaptable, incremental & efficient delivery of work. They can be applied to any type of work including finance, sales, HR, marketing, corporate strategy, leadership, and more.
I am just waiting for the day I hear a developer turn around the words of my grumpy old Color Sergeant and say back to the Project Manager - “It’s called an estimate because it is one. If it was meant to be definitive it would be called an ‘Exact’”.
Discover what a 80 year old book can teach us about dealing better with people. Find old solutions for our newer communication problems.
A practical primer on how to manage successful software development efforts.
There have been a lot of words spoken both in print and on the Internet about how to be more agile, and it can be hard to filter. I distilled my experiences down into my own hopefully-pithy maxims. Call it Bumper-Sticker Agile.
Anyone involved with hiring entry-level technology professionals is aware that students are being prepared by schools for how to do work in the industry, but are often ill-prepared on how to find work in the industry.
I’ve contemplated things around Kanban recently, and here’s another interesting perspective. It might help make more sense of the Kanban method as a method for managing knowledge work, and software development work, in particular.
The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience.
When we see only 27% of software developers are women in a world of 50% women, the fact that women are historically discriminated against is evidence that the effects of their historical oppression haven't yet been corrected
Do you have any stories showing how a few micro-habits have transformed a team’s productivity? There seems to be no written repository collecting such developer micro-habits together, and nor is there any obvious forum in which they are explored, shared and discussed. That seems a shame, and a huge waste.
Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Johanna Rothman, Agile expert, consultant, and author.
I am entering my first day as a furloughed government worker. Each day I spend back in the world of "open work", the chances of me going back to being an employee gets slimmer and slimmer.
I once interviewed a guy who was pretty good, but not a definite "yes-hire-him-now." The professor thought the student was the bee’s knees. This guy went on to join my friend’s company. When he did program something, he wouldn’t test it. It’s interesting how different work is from school.
When I speak to people about Scrum, I often hear people describe Scrum as: Waterfall but with shorter iterations. That view, IMHO, is fundamentally wrong and will lead to you not getting any of the benefits from using Scrum.
As software grows in complexity it becomes increasingly difficult to manage, maintain, build, and scale. Sometimes this can lead to inadvertent back-seat driving of a company. And without proper recognition, software development can accidentally slide into the driver's seat.
I joined a tech startup in Boston right after graduating college in 2003. Like corporate life in general, there is a ton of stuff you don’t know when you’re just graduating, but even more stuff that is startup specific. Here’s the real deal.
I think that the bottomline for each creative professional — as I believe many people in software development are creatives — is to find out when they are ready to move from the “finding their passion” stage to the “creative routine” stage.
My post “The Shame of Pair Programming” is attracting a lot more attention than I’m used to. Today I coded alone, it was fun because the work was simple. If it had been complex, I might have been fretting, frustrated, fearful, lost or despondent. I need support when I struggle.
In the last few months Steve Smith, myself and others have been Tweeting a lot with the hash tag #NoProjects. We have independently come to believe Projects are a smell, they are bad for our industry (the technology industry). Steve set out his thinking and now it is my turn.
If you are repulsed by the concept that your elbow-rubbing skill may be integral to career success, or are perhaps uncomfortable in traditional networking situations, please continue reading – it’s less necessary today than most think.
Today I want to share some more details on when it is potentially not enough to have one product owner. You might want to watch for those signs in your teams, and then act as needed.
We have to take the rough with the smooth when it comes to agile adoption. Some clients make cheering progress while others advance at a glacial pace. In short, we must be prepared to facilitate agile transformation in organizations that suck.
Failure happens. On the Internet when we talk about failure, we generally mean pictures of vehicles in strange places, large scale (and confusing) accidents and animated gifs of cats being cats. However, in Agile Business Management (and Agile in general) failure means something different.