project-management   5463

« earlier    

Clubhouse: Product Features
An online project management tool similar to JIRA
19 hours ago by mikekellogg
12. Budget Planning – Project Management
Detailed description of the steps in planning for a simple project (moving from one apartment to another)
money  budgeting  project-management 
2 days ago by amoore
Manuscript - Project Management for Software Teams
Go beyond done and craft great software with Project Management for Software Teams
collaboration  project-management  jira 
3 days ago by reorx
Scrumpy — A Beautiful Project Management Tool for Agile Teams
Scrumpy is designed for agile teams who manage multiple projects. We focus on minimalism and fun.
project-management  agile  collaboration  planning 
10 days ago by reorx
awesome-leading-and-managing/ at 5259659d43e5bcfa0962b0f980948ba82e80b5a2 · LappleApple/awesome-leading-and-managing
Awesome List of resources on leading people and being a manager. Geared toward tech, but potentially useful to anyone. - LappleApple/awesome-leading-and-managing
10 days ago by jiffyclub
Project sponsorship
This paper represents a unique and important area that is mostly underserved, and addresses the areas that senior management needs to focus on in order to promote a culture of project management excellence in their organization. It also covers specific activities they should be doing as sponsors of a project, specific things they should look for in projects they are sponsoring, and specific questions they should be asking of project managers and teams throughout the project lifecycle.
project-management  sponsors  pmi 
12 days ago by wernsting
You have to choose between Software Delivered on Time and Good Software
An essay about bridging the gap between the short-term, execution-driven world of "The Business" and the long-term, quality-driven world of Software Engineering while keeping development creative.
management  programming  software  project-management  agile 
15 days ago by seanmclucas
The State of Agile Software in 2018
- The point is, the team doing work decides how to do it. That is a fundamental agile principle. That even means if the team doesn't want to work in an agile way, then agile probably isn't appropriate in that context, and [not using agile] is the most agile way they can do things in some kind of strangely twisted world of logic.

- When I summarize agile to people, I usually say there's two main pieces to it. One, I've already talked about, the primacy of the team, and the team's choices of how they do things, but the other is our ability to change rapidly, to be able to deal with change easily.

- The third thing that I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, "Let's focus on things that are much more long-lasting and organize a product team around that." Another way of thinking about it is: what are the business capabilities that your organization has, and then organize the teams around those.

- When [at Snowbird] we were talking about names for agile software development, Kent Beck suggested "conversational", because there should be an ongoing conversation between software developers, business people, and anybody involved in making that customer experience better.

- I think Ron Jeffries joked that Allistair Cockburn's approach to agile was "come together in peace and harmony, deliver software every week, and do a retro every time to figure out how you can improve".

In particular, one of the really central things that impressed me very much about the early agile advocates was this realization that people are operating at the best when they choose how they want to work.

When we talked about the Agile Manifesto and laid out the four value statements, with most of those value statements, we didn't care very much about what order they came in. But we did have an opinion about the first one: which is "Individuals and Interactions over Processes and Tools". To me that crystallized a very important part of what agile thinking is about. If you want to succeed in doing software development, you need to find good people. You need to find good people that work together at a human level, so they can collaborate effectively. The choice of what tools they use or what process they should follow is second order. I thought that's a very important statement to come from what was basically a gathering of process weenies. I mean we were all process guys to some extent or other, and yet we were acknowledging that what we were talking about was actually of secondary importance. What matters is that the team chooses its own path.

It goes further than that for the team should not just choose the process that they follow, but they should be actively encouraged to continue to evolve it and change it as they go. One of the things about any kind of agile processes or agile method is that it is inherently very slippery. It changes week to week, month to month. One of the quotes that I used to flash around people was "if you're doing Extreme Programming the same way as you were doing it a year ago, you're no longer doing Extreme Programming".

- retrospectives are clearly a technique that lots of people find to be really very central.

- This is a reaction against the whole Frederick Taylor, separate process people.

He's probably one of the most important figures in the history of the 20th century in terms of how he's actually affected people's day to day lives. He was from the late 19th century, in America, and he was very interested in trying to make people more efficient in the industrial workplaces that were developing at that time. His view of the average worker was that they were lazy, venal, and stupid. Therefore you didn't want them to decide how they should make a particular piece of machinery, but somebody else, somebody who was a more intelligent and educated, they should figure out exactly the best way to do it. Even going down to: do I do this and then that or do I do that and then this. This is a very scripted sense of motion and movement. The whole time and motion industry came out of that. At the heart of this notion was that the people who are doing the work should not decide how to do it. It should be a separate group of planners who does this, and that strongly affected manufacturing and factory work through much of the early 20th century.

And it affected the software industry as well - people said, "we need software process experts to figure out how to do things, and then programmers just fit into the slots".

- The agile movement was part of trying to push that, to try to say, "The teams involved in doing the work should decide how it gets done," because let's face it, we're talking about software developers here. People who are well paid, well educated, hopefully, well-motivated people, and so they should figure out what in their particular case is necessary.

- And yet what I'm hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty.

- "I'm refactoring our software at the moment, so it's going to be broken for the next two weeks." Bzzz - that's not refactoring. Refactoring is small changes, each of which keeps everything working. It doesn't change the observable behavior of the software, that's its definition. And I should know because I was the one who got to define it.

Refactoring is lots of small changes, none of which change the observable part of the software, but all of which change its internal structure.

- So my three things, that we should face as challenges:

1. Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
2. Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
3. organize around products.
agile  scrum  extreme-programming  software-development  details  business  project-management  product-developmentment 
22 days ago by hellsten
Engineering creativity
A birds-eye view of Wiredcraft's approach to human-centric design projects, or "Why we think most creatives are bullshit and how our team engineers creativity."
design-process  ux  project-management  approach 
4 weeks ago by marius.marinescu

« earlier    

related tags

accessibility  advice  agency  agile  app-web  app  approach  around-the-web  best-practices  bolt  bootcamp  budgeting  business  charts  collaboration  construction  consulting  continuous-integration  cool-tools  critique  crm  culture  darpa  dashboard  data-science  design-process  design  details  development  digital-scholarship  document-template  dsdm  education  emacs  email  engineering-management  estimation  extreme-programming  favorites  gantt  git  github  google  graphics  gtd  handoff  interfaces  issue-tracking  javascript  jira  jobs  js  kanban  lerna  macos  management  meeting  modelling  money  monorepo  okr  online-tool  open-source  opensource  philosophy  planning  pm  pmi  premortem  preservation  process  product-developmentment  product-management  productivity  programming  project-organisation  project  projects  projekt-management  proposal  proposals  quality  repository  requirements-analysis  research  resource  roadmap  safe  scoping  scrum  service  software-development  software  sponsors  sprint  team-tools  team  this-week-436  time-management  time-tracking  time  timetracking  tool  tools  trello  type:application  ui  ux  visualization  webapp  weekly.rc  work  workflow  worklife  workspace  workspaces  writing  ycombinator 

Copy this bookmark: