Boxes and lines diagrams *can* work very well, but there are many pitfalls associated with sketching software architecture in this way. My approach is to use a collection of simple diagrams, each showing a different level of abstraction.
I don't agree with the opinion that Story Points are better for estimation than Ideal Days. When we do estimates, we use Ideal Days, because thinking this way is more natural and more useful, and because these estimates are more meaningful to people inside and outside of the team.
Like it or not, performance-based pay is a reality of our industry. David Bland looks at some practical/useful tips and techniques on how software companies could implement performanced-based pay effectively and fairly.
Agile is no longer the prevue of pioneers and visionaries. Agile shows up in the popular business press. PMI is all over it. but Many managers in organizations with traditional functional hierarchies want the benefits of agile –without disrupting the status quo. Not going to happen.
The iteration is a cornerstone of agile development. However, the way many teams run their iterations creates serious pitfalls which can keep them from delivering software as effectively as they could.
Computing technology has reached a critical level where we are going to see all kinds of amazingly useful (and not just quirky) gadgets. And then people then will find ways to bring them together into single robot models. The jobs of the future will be be in how to make things that are going to make obsolete the things that human beings do.
So how can one protect his job – simply by making sure that his manager and managers are aware of the state of the tasks under his responsibility and if a deadline is going to be missed, notify them about it as soon as possible, because no manager loves surprises as far as his project is concerned.
If you see anything about LMAX - the Disruptor, Continuous Delivery, or even the selection criteria for hiring developers, you'll see that LMAX is pretty keen on Agile. However, no-one's documented the Agile process there, as far as I know.
When I started working for a software house our work was mostly made up of building and fixing, we were told what to build, didn’t do it very well and spent most of our time fixing it. Today our daily activities are a bit different so I thought I’d try to break them down